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ABSTRACT 


This project report describes a proposed foundation for a system-of-systems 
training architecture that closes gaps in the Navy’s current strike group training processes 
to more effectively train and support warfighters in the execution of a webfires concept. 
Today’s fleet training systems lack the capability and capacity to provide adequate 
integrated training that leverages the necessary high-velocity learning expected of future 
warfighters who will employ and implement the webfires concept in the next 10 to 15 
years. The current training processes and systems fail to provide sufficient hardware/ 
software integration, training repetition, and performance feedback necessary to prepare 
warfighters to employ webfires against a near-peer threat. 

This report details requirements that a future training system should possess to fill 
gaps in the Navy’s current training process and align it with the Optimized Fleet 
Response Plan. It contains actionable recommendations for stakeholders and identifies 
key technology development areas that will enable a future webfires system. This report’s 
recommendations will improve the way the Navy conducts fleet training and will create a 
competitive advantage in the maritime environment. 
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EXECUTIVE SUMMARY 


The nature of naval warfare is continuously evolving. The traditional kill chain 
approach is expected to be insufficient to neutralize near-peer threats in the future. To 
increase the combat effectiveness of the U.S. Navy in a future combat environment, the 
Navy is shifting its warfighting approach to a kill web, or webfires, concept of 
operations. In his 2016 interview with the U.S. Naval Institute, Admiral Manazir postures 
that unlike the current kill chain process in which units are limited to engagements 
utilizing organic sensor data, future units will instead be able to work together to “create 
a cross-domain kill web” able to share combat-relevant data for the purpose of tracking 
and engaging an adversary. This shift in the way the Navy fights calls for a new approach 
to training the Navy’s future warfighter. This report details a systems engineering 
approach for developing a webfires training system (WFTS) to prepare the future 
warfighter for an engagement with a near-peer threat. 

A. SCOPE AND ASSUMPTIONS 

Due to time constraints and still-maturing Webfires concepts, the team applied 
some significant assumptions and boundaries to scope the problem to a manageable level. 
These assumptions allowed the team to focus their efforts into determining capability 
gaps in the Navy’s current training system, generating a base list of requirements for the 
future WFTS to meet, identifying key software/hardware capabilities, selecting the main 
organizations that will support training and their tasks, and research technology that will 
support these functions and organizations. Completion of these tasks allowed the team to 
build a foundation upon which a full system architecture can be built in the future. 

B. CAPABILITY GAPS 

Stakeholder Analysis identified four key capability gaps: the absence of any 
webfires concept training today, a lack of multi-unit training repetition to support high- 
velocity learning, a lack of compatible networks to support integration of units and 
simulators for webfires training, and a lack a quality feedback to facilitate high-velocity 
learning. 
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The Navy is currently developing the webfires concept. The recent deployment of 
the first capable Naval Integrated Fire Control - Counter Air (NIFC-CA) strike group 
demonstrates that such a concept is being developed and implemented by the fleet. The 
implementation of NIFC-CA is just one small aspect of the webfires concept. If all 
Carrier Strike Group or Expeditionary Strike Group (CSG/ESG) units are able to share 
fire control data with each other, then the webfires concept can be implemented across 
the air, surface, and undersea warfare domains, which is consistent with Admiral 
Manazir’s vision for networked warfare as discussed with the U.S. Naval Institute in 
September 2016. Eor warfighters to implement this advanced weapons system 
effectively, they require doctrine. This capstone report recommends that the Naval 
Warfare Development Center (NWDC) coordinate with the other warfare development 
centers to document a unified set of tactics, techniques, and procedures (TTPs) that are 
used by all warfighters to implement and train for webfires. 

Additionally, the network capability of today’s training system is not robust 
enough to support the repetition necessary to facilitate high-velocity learning and in turn 
results in less efficient multi-unit training. Currently, the only complete CSG/ESG multi¬ 
unit training is performed during Composite Training Unit Exercises (COMPTUEX) 
within the integrated phase of the Optimized Elect Response Plan (OERP) to certify a 
CSG or ESG for deployment and entry into the sustainment phase of the OERP. 
Currently, the Tactical Training Groups (TTG) have the ability to facilitate fleet synthetic 
training (EST) events prior to COMPTUEX. However, due to the nature of the training 
network and the reliance on large numbers of people to conduct these EST events, the 
TTGs can only perform one simulation at a time. A more robust, decentralized training 
network along with a database of preprogrammed training simulations will greatly 
increase the potential for more frequent integrated training. 

Easily, repetition is only one aspect of high-velocity learning. Eor high-velocity 
learning to work, training must be current, accurate, and relevant. This report 
recommends that the future WETS collect and produce data that is used by the NWDC to 
assess the current engagement doctrine. By incorporating a feedback loop into the 
training system, the doctrine can be updated to reflect better approaches to attack an 



enemy during the training process, and correct deficiencies discovered in the doctrine. 
Additionally, the collected data may be used by the appropriate teams in certifying and 
evaluating units for deployment. This could potentially reduce training and certification 
requirements. However, for this feedback loop to work, the NWDC, along with the 
certification and evaluation teams, must establish well-defined data collection 
requirements. 

C. REQUIREMENTS 

Based on the identified Capability Gaps, the team developed the following 
capability requirements for the WFTS: 

1. Webfires Concept Training Requirements 

a. Fit into the basic, integrated, and sustainment phases of the OFRP 

b. Integrate training during both unit and multi-unit training 

c. Integrate training during in-port and at-sea 

2. Repetition Requirements 

a. Provide standardized training scenarios for unit and multi-unit training 

b. Provide training capability in a limited communication environment 

c. Capable of allowing units and simulators to independently establish 
their own training networks for simulation. 

d. Shall integrate with future strike group units’ networks, training 
facilities, and simulators 

3. Feedback Requirements 

a. Provide data that can be used to assess doctrine against a near-peer 
threat 

b. Provide data that can be used to aid certification and evaluation of 
units during the OFRP. 
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D. FUNCTIONAL ANALYSIS 


The functional analysis identified key functions that the future training system 
must meet in order to satisfy capability requirements and fill capability gaps. The 
functional analysis looked at both hardware/software function and organization functions/ 
responsibilities that are performed. Most notably, this report identifies the key 
organizations that will be involved in this future training system and their tasks. Those 
organizations are the Intelligence Community, NWDC, TTGs, Numbered Fleets, CSG-4/ 
15, Operational Strike Group Commanders, CSG/ESG Units, and their embedded 
simulators. These organizations must jointly produce effective webfires training 
objectives to create future simulations that will aid CSG/ESG unit training to a near-peer 
threat level. Additionally, these organizations must establish effective data requirements 
that the WETS must meet in order to aid certification and evaluation and allow the 
NWDC to assess webfires doctrine and update it accordingly. 

E. SYSTEM ARCHITECTURE 

This report develops a foundation upon which a more in-depth system 
architecture can be produced once webfires systems components are online. The most 
significant aspect of this foundation is the identification of the Nodes, Operational 
Activities, Eunctions, and enabling Components. Eigure 1 shows the process used to 
design and create this foundation. 

• Nodes are the organizations that are involved in this training system. 

• Operational activities are the tasks that the organizations have to perform 
in order to support training, increase repetition, and provide high-velocity 
learning. 

• Eunctions support and enable the operational activities. 

• Eunctions are performed by components. 
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Adapted from CORE Architecture Definition Guide (DoDAF v2.02) 
Figure 1. WFTS Foundational Architecture Flow 


F. WFTS RECOMMENDED TECHNOLOGIES 

Since the webfires concept is still in its infancy, this project focuses on general 
technological capabilities that the WFTS components must possess to facilitate repetition, 
high-velocity learning, and performance feedback. Using an analysis of alternatives 
approach, this report identifies the technologies that would be most useful in comprising 
the WFTS. These significant technologies are: 

• Artificial intelligence systems or automated systems to play red forces 
during simulations. 

• An advanced mesh network topology. 

Current multi-unit simulations conducted by the Navy are people-intensive. 
Simulations require a large number of personnel to play the red force. This in turn limits 
the number and the frequency of quality simulations that are performed at any given time. 
By augmenting simulations with a red force played by some sort of artificial intelligence 
or automated responses, the quality and quantity of training can be increased. 
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The current training network is essentially comprised of a star network topology 
with the TTGs acting as the central node to coordinate and connect units and simulators 
to the training network. To increase training repetition and high-velocity learning for 
units in port and at sea along with the incorporation of land-based simulators, a more 
decentralized network topology is needed. The difficulty of implementing a mesh training 
network is compounded by information assurance issues, lack of sufficient network 
connections, and lack of sufficient training network interfaces to stimulate combat 
systems on ships. 

G. ANALYSIS OF ALTERNATIVES 

A morphological box is used in this study to develop nine design alternatives. 
These nine design alternatives were developed to showcase nine different aspects the 
WFTS should be capable of performing. Qualitative comparisons are used to rank each of 
the nine alternatives. These alternatives helped the team determine which aspects of the 
WFTS may provide the biggest benefits for a training system focused on high-velocity 
learning. The analysis and alternatives section in the report discusses each of the nine 
alternatives and the results of all comparisons. The intent in comparing alternatives was 
not to limit selection to one finalized recommended design, but rather to highlight 
additional possibilities regarding capabilities and limitations to use for further research 
and development of the WFTS. 

H. ITEMS FOR FURTHER RESEARCH 

Through research and stakeholder interviews, the authors discovered multiple 
relevant topics with respect to training, webfires, and webfires training. Due to time 
constraints and project scope, the team was unable to explore many of these extremely 
relevant topics. However, these topics are important for implementing webfires, 
advancing the implementation of a WFTS, and improving warfighter training in general. 
This report recommends that further research on the following topics would be in the best 
interest of the Navy: 



Communication network advancement. 


• Artificial intelligence and machine learning. 

• Navy Training Systems Plan for the WFTS. 

• Technology to augment face-to-face briefing and debriefing. 

• Information assurance. 

• The importance and incorporation of more SMEs in the training process. 

1. CONCLUSIONS 

The key to providing high-velocity learning is increasing repetition, providing 
effective feedback, and providing quality training. The future WFTS will provide high- 
velocity learning by incorporating rapid data feedback, simulations, and increased 
connectivity. 

• Clear data collection, processing, and distribution requirements must be 
established 

• Investment into being able to provide simulations using real warfighting 
equipment must be made to increase the quality of training 

• Information Assurance requirements, network topology, and 
communications bandwidth limitations must be addressed to allow more 
repetition and repeatability 
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I. 


INTRODUCTION 


The United States Navy (USN) has been the cornerstone of the nation’s power 
projection and security for over 240 years. To sustain such an obligation under an ever- 
changing and dynamic environment, the Navy must develop the concepts and capabilities 
to provide our national leaders with options for handling situations ranging from non¬ 
conflict stability operations to near-peer combat at sea. 

Current combat systems are often closely linked among the various forces of a 
strike group. The concept of integrating unmanned systems into distributed lethality and 
the ability to communicate among distant forces to provide overwhelming offensive 
firepower against an adversary was evaluated in a previous systems engineering analysis 
capstone report (Erstad et al. 2016). The distributed lethality construct rapidly expanded 
into the proposed webfires concept, which integrates the air, surface, and sub-surface 
domains in a highly-connected network to achieve unparalleled communication and fire- 
support abilities among the various elements of a strike group. Systems Engineering 
Analysis Cohort 25, collectively referred to as “the team” for the remainder of the report, 
was tasked to develop a training architecture to enable the adoption of the previously 
described webfires concept. This architecture will leverage the potential technologies of 
the 2025 to 2030 timeframe and use the principles of high-velocity learning as the 
foundation of the training system. 

A. ORGANIZATION OF THE REPORT 

The entire project is documented in 12 chapters. These chapters are organized in a 
way that mirrors the process the team followed to create the training system architecture. 
The team began by examining several systems engineering process models, which are 
described in a later section of this chapter, and chose an appropriate systems design 
approach. The report follows the team’s efforts to understand the problem, identify and 
analyze gaps, generate system architectures, and ultimately recommend a comprehensive 
design that is not only appropriate to the tasking, but also satisfies the stakeholders’ 
needs. 
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The first three chapters provide for the framework and context of the problem. 
Chapter I, “Introduction,” provides an overview of the project, including project 
background, project team, the foundations on which the project is built, systems 
engineering process models, and system design approach. Chapter II, “Problem 
Definition,” provides an analysis of the true nature of the tasking statement and the 
problem statement that the team derived from it. This chapter also defines terminology 
essential to the understanding of this system architecture as well as the assumptions and 
boundaries to the problem that are critical to framing the proposed training system within 
the context of the larger webfires concept. Chapter III, “Needs Analysis,” summarizes the 
process to discover the needs of the stakeholders and the specific issues that were raised 
through research, stakeholder site-visits, and interviews. 

The next three chapters analyze the current training system and how integration 
plays a part, as well as analyzing and comparing the current system to the needs of the 
proposed webfires training system (WFTS). The third chapter in this section provides an 
overview of the purpose and methodology of the future training system. Chapter IV, 
“Current Training Process,” details the methods and process that current naval personnel 
undergo to achieve individual qualifications as well as unit level qualifications. Chapter 
V, “Gap Analysis,” compares the current process to the defined needs of the future 
system as discovered through stakeholder interviews. This analysis presents several 
major gaps that the proposed system architecture will attempt to resolve. Chapter VI, 
“Concept of Operation,” details the general process that personnel and units will undergo 
in the proposed WFTS. 

Chapters VII through X capitalize on the identification of gaps and the problem 
definition to lay out a system-of-systems design. Chapter VII, “System Requirements,” 
looks at both the capabilities and requirements that a system must possess in order to fill 
the gaps that are determined in Chapter V. Chapter VIII, “Functional Analysis,” identifies 
the system functions, both people and material, that the system must have to meet the 
requirements identified in Chapter VII. 

Chapter IX, “Analysis of Alternatives,” presents the process that the team used to 

complete an analysis of alternatives. This analysis enabled the team to identify which 
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design option best addresses the gaps identified in Chapter V. Chapter X, “System 
Architecture,” combines all of the efforts of the previous chapters and formulates a 
comprehensive system architecture. 

Finally, this report concludes with a Chapter XI, “Summary, Conclusions, and 
Recommendations.” The final chapter summarizes this report’s findings, contains a 
detailed list of conclusions along with actionable recommendations, and a list of 
recommended topics for further research. The various appendices at the end of the report 
contain the official tasking statement, amplifying information for certain chapters, and 
Institutional Review Board (IRB) approved questions and documentation. 

B. PROJECT BACKGROUND 

The capstone project officially started in September 2016 during the fall 2017 
academic quarter. The team was required to identify and integrate students from the 
National University of Singapore’s Temasek Defense Systems Institute (TDSI), as well 
as students and faculty of relevant Naval Postgraduate School (NPS) programs into the 
project to provide technical knowledge and insights and aid in research and report 
writing. The team then had three quarters to deliver a completed project report and final 
briefing materials to NPS faculty advisors and the Pentagon. The team received official 
tasking from the Office of the Chief of Naval Operations (OPNAV) Deputy Chief of 
Naval Operations for Warfare Systems - Integration Division (N9I). 

C. PROJECT TEAM 

NPS enrolls and educates a diverse set of military officers from around the world 
in several graduate schools and degree programs. The Systems Engineering Analysis 
(SEA) team comes from an interdisciplinary program from both the Graduate School of 
Engineering and Applied Sciences (GSEAS) and the Graduate School of Operational and 
Information Science (GSOIS). The resident students critical to the success of this project, 
as well as their warfare backgrounds, are listed in Table 1. 
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Table 1. Resident Team Members 


Rank and Name 

Service 

Warfare Desisnator and Past Experience 

LCDR Daniel DeCicco 

USN 

Naval Aviator, MH-60S 

LT Matthew Alvarez 

USN 

Naval Aviator, MH-60S/SH-60F/HH-60H 

LT Benjamin Arnett 

USN 

Naval Aviator, MH-60S 

LT Michael Hook 

USN 

Surface Warfare Officer, CRU/DES 

LT Austin Thompson 

USN 

Submarine Warfare Officer, SSBN 

LT Kevin Weeks 

USN 

Surface Warfare Officer, CRU/DES 

LT Seng Yee 

USN 

Information Professional Officer, CRU/DES 


Supplementing the core team are students that have completed at least six months 
of graduate education at Singapore’s TDSI. These students are required to contribute to 
this project in partial fulfillment of their own degree requirements. Additionally, these 
individuals bring a wide variety of knowledge and experience to the table, even as they 
are working in their own academic disciplines and completing individual theses. Their 
specialties are in the areas of operational research, computer science, mechanical, 
electrical, and weapon systems engineering, oceanography, and physics. These specialists 
and their backgrounds are listed in Table 2. 
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Table 2. TDSI Cohort Members 


Rank & Name 

Service 

Background and Course of Study 

LT Ryan Beall 

USN 

Naval Aviator, MH-60S (Systems 

Engineering) 

LT Preston Tilus 

USN 

Surface Warfare Officer, CRU/DES 
(Operational Research) 

LTJG Clayton Petty 

USN 

ADM Prank Bowman Scholarship 
(Mechanical Engineering) 

MAJ Dor Kronzilber 

IDE 

Army Officer (Operational Research) 

ME5 Ang Chin Beng 

RSAP 

Air Porce Engineer (Weapon Systems 
Engineering) 

ME5 Kang Wei Sheng 

SA 

Army Engineer (Systems Engineering) 

ME5 Ang Pak Siang 

RSAP 

Air Porce Engineer (Communications 
Engineering) 

CPT Ang Wee Kiong 

SA 

Army Intelligence Officer (Systems 
Engineering) 

MAJ Hoon Dingyao 

SA 

Signals Officer (Computer Science) 

CPT Gay Wee Choon 

SA 

Armor Officer (Operational Research) 

MAJ Soh Yuan Wei 

SA 

Combat Engineer Officer (Systems 

Engineering) 

Yee Jian Hong 

DSTA 

Advanced System (Weapon Systems 
Engineering) 

Ang Cheng Hai 

DSTA 

Air System (Communications and Network 
Engineering) 

Han Keng Siew 

DSTA 

Network Systems (Systems Engineering) 

Poo Yueng Hao 

DSTA 

Communications Infrastructure (Computer 
Science) 

Chin Hon Keong 

Civilian 

Defense 

Industry 

Eand Systems (Weapon Systems Engineering) 

See Hongze 

Marine Systems (Systems Engineering) 

Toh Ying Jie 

Electrical and Electronic Systems (Systems 
Engineering) 

Eai Wee Eeong 

Electrical and Electronic Systems (Systems 
Engineering) 

Tan Choon Seng 

Aerospace Systems (Weapon Systems 
Engineering) 


The team has been supported by many faculty members through mentorship and 
instruction during their graduate education. Without the support, superior knowledge, and 
practical experience of the lecturers and faculty advisors, the team would not be able to 
focus their work into a meaningful discussion in the form of this report. The faculty 
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advisors and subject matter experts (SMEs) especially critical to the success of this 
project, as well are their respective departments, are listed in Table 3. 


Table 3. Resident Faculty Advisors 


Rank and Name 

Role 

Experience 

Dr. Fotis Papoulias 

Advisor 

NPS Associate Professor, Systems 
Engineering 

Dr. Michael Atkinson 

Advisor 

NPS Professor, Operational Research 

CDR (Ret.) Bill Hatch, USN 

Advisor 

NPS Professor, Manpower Systems 
Analysis 

CAPT (Ret.) Jeffrey Kline, 
USN 

SEA 

Chair 

NPS Professor of Practice, Operations 
Research 

CAPT Chuck Good, USN 

SME 

COMNAVSURFPAC Detachment, 
Monterey 


D. PROJECT FOUNDATIONS 

The recommendations within this report are based on the foundations of the Chief 
of Naval Operations’ (CNO) vision statement titled A Design for Maritime Superiority. 
Contained within are various lines-of-effort (LOE) that contribute to this vision and some 
principles that enable them (Richardson 2016). Innovation and critical thinking play 
heavily into the Admiral Richardson’s vision (2016), and accordingly, the capstone 
process began in earnest with participation in the annual Warfare Innovation Continuum 
(WIC) Workshop sponsored by the Consortium for Robotics and Unmanned Systems 
Education and Research (CRUSER), held each fall at NPS. 

1. The UNO’s Design for Maritime Superiority 

The UNO’s 2016 vision contains several critical EOEs that provide a backdrop for 
the implementation of the WETS. The maritime superiority design concept, in addition to 
the proposed webfires concept, draws a focus on fleet-wide readiness to engage in a naval 
battle in all waters and air spaces. According to the CNO (2016), the primary concepts 
for implementation focus on the following six pinnacles: 
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1. Maintain and modernize the undersea leg of the strategic deterrent triad. 

This is foundational to our survival as a nation. 

2. In partnership with the Marine Corps, develop concepts and capabilities 
to provide more options to national leaders, from non-conflict competition 
to high-end combat at sea. Operations short of conflict should be designed 
to contain and control escalation on terms favorable to the U.S. Combat at 
sea must address “blue-water” scenarios far from land and power 
projection ashore in a highly “informationalized” and contested 
environment. All scenarios must address the threat of long-range precision 
strike. Test and refine concepts through focused wargaming, modeling, 
and simulations. Validate these concepts through fleet exercises, unit 
training, and certification. 

3. Further advance and ingrain information warfare. Expand the 
Electromagnetic Maneuver Warfare concept to encompass all of 
information warfare, to include space and cyberspace. 

4. To better meet today’s force demands, explore alternative fleet designs, 
including kinetic and non-kinetic payloads and both manned and 
unmanned systems. This effort will include exploring new naval platforms 
and formations—again in a highly “informationalized” environment—to 
meet combatant commander needs. 

5. Examine the organization of United States Elect Eorces Command, 
Commander Pacific Elect, and their subordinate commands to better 
support clearly defining operational and warfighting demands and then to 
generate ready forces to meet those demands. 

6. Examine OPNAV organization to rationalize our headquarters in 
support of warfighting requirements. Warfare Innovation Continuum. 
(Richardson 2016, 6) 

Also critical to the success of the WETS is the introduction and use of high- 
velocity learning. This is a primary tenet of the CNO’s vision. In the NPS Update 
newsletter dated August 2016, Kenneth A. Stewart summarizes the origin of high- 
velocity learning: 

The term high-velocity learning was penned by Steven J. Spear in his 
book. The Velocity Edge. This innovative model explores methods for 
building a system of “dynamic discovery” for seeing and solving problems 
as they occur, sharing information to help convert weaknesses into 
strengths, and developing leaders who are invested in their subordinates’ 
successes. (Stewart 2016, 3) 
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It is important to note that high-velocity learning is a skill and, like any other 
skill, it requires practice. 

2. Warfare Innovation Continuum Workshop 

The annual WIC workshop is a themed and coordinated effort to leverage NFS 
cross-campus educational and research activities as well as technology and defense 
industry personnel to explore innovative solutions and “apply emerging technologies to 
shape the way we fight” (CRUSER 2016). The main thrusts of the CNO’s vision, as well 
as how the foundations of systems engineering will contribute to its success, are 
expanded upon in the following paragraphs. 

The timeline for the annual WIC is displayed in Figure 1, where the important 
capstone deadlines are annotated in addition to some coursework and academic 
milestones. As the graphic shows, the WIC Workshop was held in September 2016, and 
the capstone report is due in June 2017. 



Source: CRUSER (2016). 

Figure 1. 2016 WIC Timeline and Project Milestones. 
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In the fall of 2016, a continuum focused on naval power in the littorals and titled 
Developing Autonomy to Strengthen Naval Power was held at NPS (CRUSER 2016). The 
purpose of this conference was to integrate members from a variety of backgrounds to 
apply creative-thinking skills and propose unique solutions to a theoretical future combat 
problem. The diverse personnel in attendance included warfare-qualified U.S. military 
officers and civilians enrolled in various degree programs at NPS, engineers from Silicon 
Valley and Department of Defense (DOD) laboratories, and accomplished members of 
the academic community. 

a. WIC Workshop Focus Areas 

As found on the WIC Sakai website, this group of diverse professionals 
concentrated their incorporation of ideas and technologies into three main discussion 
areas: 


1. Littoral Mesh Networking and Remote Sensing: These concepts all 
employ autonomy to create a mesh network of communications and 
sensing nodes in a contested urban littoral environment. Concepts in this 
category include Remote Aerial Vehicle Information Network (RAVIN), 
“Soccerball” Small Distributed Phased-Array Jammer, Civil 
Infrastructure: Autonomous Support for HA/DR, Ground Surveillance 
System Deployable ISR Packages, and the Robotic Self-Healing Mesh 
Network. 

2. Innovative Undersea Warfare: These concepts leverage autonomy to 
clear and secure sea lanes and harbor approaches for landing and resupply 
in a contested urban littoral environment. Concepts in this category 
include HYDRA Shield and Autonomous Guard. 

3. Autonomous Unmanned Submersible Missions: These concepts 
employ autonomy to leverage or disable all available assets in a contested 
urban littoral environment. Concepts in this category include USVs of 
Opportunity and “The Heisman” Autonomous Bumper Boat. (CRUSER 
2016) 

b. WIC Workshop Results 

The four-day effort culminated in presentations to military and industrial leaders, 
highlighting complex, innovative, and synergistic solutions to these main topics. A final 
For Official Use Only (EOUO) report was generated based on the work and is available 
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to authorized users. The results of this continuum align with the CNO’s vision and lay the 
groundwork for this report. 

E. SYSTEMS ENGINEERING 

Early on in the graduate program, the team learned several accepted definitions of 
“systems engineering” and unique tenets apply to the field. The preeminent governing 
body of systems engineering, the International Council on Systems Engineering 
(INCOSE), has published a thorough and widely used definition. According to the 
INCOSE website: 

Systems Engineering is an interdisciplinary approach and means to enable 
the realization of successful systems. It focuses on defining customer 
needs and required functionality early in the development cycle, 
documenting requirements, then proceeding with design synthesis and 
system validation while considering the complete problem: 

Operations, Performance, Testing, Manufacturing, Cost and Schedule, 
Training and Support, and Disposal. 

Systems Engineering integrates all the disciplines and specialty groups 
into a team effort forming a structured development process that proceeds 
from concept to production to operation. Systems Engineering considers 
both the business and the technical needs of all customers with the goal of 
providing a quality product that meets the user needs. (INCOSE 2017) 

I. Process Models 

It is very important for the project team to review and understand different types 
of systems engineering process models in order to choose and apply an appropriate one. 
There are three well-known systems engineering process models described by Blanchard 
and Eabrycky’s Systems Engineering and Analysis textbook. Erom these process models, 
the team has selected a systems engineering process model that best supports the project. 

a. Waterfall Model 

The first systems engineering process model is the waterfall process model. The 
waterfall model is a linear sequential model. According to Blanchard and Eabrycky, “this 
model consists of five to seven series of steps or phases for systems engineering or 
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software development and eaeh phase is earned out to eompletion in sequenee until the 
produet is delivered” (Blanehard and Fabryeky 2011, 36). 

Ideally, this is the most efficient process model; however, in reality issues always 
come up during the systems engineering process. Based on this model, problems are not 
discovered until the next phase is delayed or the system is completed. As a result, this 
model lacks the flexibility for instant feedback throughout the entire process. 
Nevertheless, in this project, the team requires adopting a systems engineering process 
model that provides flexibility and feedback throughout that process to develop the 
desired system. The waterfall model is shown in Figure 2. 



Adapted from Blanchard and Fabryeky (2011). 


Figure 2. Waterfall Process Model. 


b. Spiral Model 

The second systems engineering process model is the spiral process model. 
According to Blanchard and Fabryeky, “the spiral model is an adaptation of the waterfall 
model and it incorporates feedback into the process. It is iterative and proceeds through 
several phases each time a different type of prototype is developed” (Blanchard and 
Fabryeky 2011, 37). 
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This model is known to be very time consuming and difficult to manage. Due to 
the compressed nature of the project tasking, the team requires a systems engineering 
process model that is less time consuming and more manageable throughout the systems 
engineering process, and therefore the team did not choose this model. The spiral model 
is shown in Figure 3. 



Source: Boehm (2000). 


Figure 3. Spiral Process Model. 
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c. 


“Vee” Model 


The third systems engineering process model is the “Vee” process model. The 
“Vee” model is an extension of the waterfall model and incorporates feedback loops 
throughout the process. According to Blanchard and Fabrycky, “this model starts with 
user needs on the upper left, proceeds down the left side of the “Vee” and across at each 
level, ending with a user-validated system on the upper right” (Blanchard and Fabrycky 
2011, 37). This model is less time consuming than the spiral model. Based on these 
advantages, the “Vee” model is most suited for the capstone project. A graphic depiction 
of the “Vee” model is shown in Figure 4. 



Source: Clark (2009). 


Figure 4. “Vee” Process Model. 


2. Selected Design Approach 

The team approached the training system design with a five-step process most 
similar to the “Vee” model. The first step is to clearly define the webfires concepts and 
identify its boundaries so that its training requirements are identified. The second step is 
to conduct gap analysis on current platform-centric training and compare it to webfires 

required training in order to leverage cross-domain and cross-platform technologies. The 
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third step is to understand the training needs and generate thorough training requirements. 
The fourth step is to develop a training system architeeture. The fifth step is to produce a 
complete training system design to support webfires concepts. These steps occur 
iteratively until the proposed system architecture satisfies all of the defined needs and 
requirements of the system. The selected system design approach is shown in Figure 5. 
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Entry into the cycle occurs at “Webfires Concepts” and proceeds clockwise around, 
finishing at “System Design.” However, each double arrow represents an iterative 
process that may require revisiting previously completed steps. 

Figure 5. System Design Approach 
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II. PROBLEM DEFINITION 


According to Systems Engineering and Analysis, “The systems engineering 
process generally commences with the identification of a ‘want’ or ‘desire’ for something 
based on some ‘real’ deficiency” (Blanchard and Fabrycky 2011, 57). Often times, the 
stakeholder has a want or a desire to fix a specific deficiency, but may not truly 
understand the actual nature of the deficiency. That is why as part of the systems 
engineering process, stakeholders must be interviewed to aid the systems engineers in 
determining a “comprehensive statement of the problem [with] specific qualitative and 
quantitative terms and in enough detail to [define the] ‘real’ problem and its 
importance” (57). 

A. TASKING STATEMENT AND PROBLEM STATEMENT 

In October of 2016, the team received its tasking statement from OPNAV N9I, 
the government sponsor for the Systems Engineering Analysis Curriculum and the 
primary stakeholder for this project. The official tasking statement is in APPENDIX A. 
After receiving the tasking statement, the team established smaller working groups in 
order to research, identify, and interview stakeholders; make critical assumptions; and 
scope the project to an appropriate level. Through this process, the team was able to 
discern and analyze the underlying problem that this capstone project addresses. 

1. Tasking Statement 

Design a fleet system of systems and concept of operations for employment of a 
cost effective training system capable of preparing naval warfighters to employ and 
leverage the webfires concepts and technologies in the 2025-2030 timeframe . 

• Consider training across warfare missions and specialties. 

• Conduct research to provide a solid foundation of knowledge requirements 
for a webfires fleet concept. 

• Complete a gap analysis by comparing current fleet training with the 
required training to leverage cross-domain and cross-platform capabilities 
in a warfighting environment. 
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• Scan for current examples of cross-domain training and current training 
simulation from DOD and industry. 

• Develop a system architecture addressing responsible command, training 
requirements, training and exercise venues, and training participants to fill 
discovered gaps in meeting the knowledge requirements. 

• Assess the proposed system against the principles of high-velocity 
learning found in the CNO’s A Design for Maintaining Maritime 
Superiority. (Appendix A) 

The italicized and underlined text of the tasking statement indicates the topics that 
the team focused and built upon. The tasking statement identified several key aspects that 
the team used to conduct research, outline stakeholder interviews, and develop critical 
assumptions. The analysis of the tasking statement enabled the creation of the actual 
problem statement that gives direction and scope to capstone the report. 

2. Problem Statement 

Through the process just delineated, the team crafted the following problem 
statement: 

Develop a cost-effective operational training system architecture for a webfires 
concept. The system architecture will help support training on webfires specific 
evolutions during the basic, integrated, and sustainment phases of the OFRP. The 
proposed training system will enable CSG/ESG units to successfully conduct missions in 
the 2025-2030 timeframe by leveraging high-velocity learning with current and future 
technology. 

This chapter also provides definitions of key terms: Cost Effective, Webfires, and 
High-Velocity Learning. These definitions support an understanding of the terminology 
used with respect to this research. Additionally, critical assumptions and boundaries are 
defined and discussed in order to effectively scope this report. 

B. ASSUMPTIONS 

According to The Thinkers Guide to Engineering Reasoning, “Reasoning can be 
only as sound as the assumptions on which it is based” (Paul, Niewoehner, and Elder 
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2013, 36). Therefore, it is important that engineers are clear about the assumptions they 
make, that the reasons for the assumptions are justifiable given the problem, and that the 
assumptions are consistent with each other (2013). The assumptions for this report are 
listed in Table 4. 


Table 4. Assumptions 


Critical Assumption 

Justification 

Funding 

The Navy has the intention of developing and investing 
in a webfires concept, and there will be a need for 
training system. Therefore, it is assumed that the Navy 
will provide resources necessary to develop such a 
training system. 

Fully Developed Tactics 

The webfires concept is being developed by multiple 
organizations, while the Warfare Development Centers 
(WDCs) are working on the technology and tactics that 
are associated with implementing the system. By the 
year 2025-2030 it is assumed that the webfires concept 
will have been integrated into the fleet and that the 
tactics, doctrine, and procedures will exist. 

Current Training 
Infrastructure 

The current training infrastructure (schoolhouses, 
simulators, and other training facilities) will support 
the proposed WFTS. 

Webfires Relevancy 

Based on the enemy threat and the need for the Navy to 
continually maintain and advance maritime superiority, 
webfires will aid in this ability and will therefore still 
be applicable to the Navy in the future. 

Personnel Requirements 

Personnel requirements to support webfires will not 
drastically affect the current Navy personnel 
requirements. This does not assume any change in 
future manpower requirements. 

Future Technology 

Evolutionary technology and assumed technological 
advancements that will occur between now and the 
years 2025-2030 in support of such a training system 
will be produced using these assumed technologies. 


C. BOUNDARIES 

Boundaries are understood as a defined limit to an area. When applying this 
definition to an engineering problem, boundaries define the limits of that problem. By 
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making appropriate assumptions and defining realistie boundaries in aeeordanee with the 
problem statement, engineers are able to seope a problem in a way that allows a realistie 
solution to be drafted. The boundaries for this report are listed in Table 5. 


Table 5. Boundaries 


Critical Boundary 

Justification 

Administrative 

Boundaries 

The team will only look at the Fleet Forees Command level and 
below with respeet to the administrative boundaries of the 
system. Ineorporating higher administrative levels, to inelude 
joint units and other DOD entities, would unneeessarily 
eomplieate and inerease the seope of the projeet. 

Operational 

Boundary 

The team will only look at the Commandant Command level 
and below with respeet to the operational boundaries of the 
system. Ineorporating a higher national eommand perspeetive 
would unneeessarily inerease the seope of the projeet. 

CSG/ESG Units 

While the eoneept of webfires may eventually be applied to 
interaetions between joint serviees and allied nations, for the 
purpose of this projeet, the seope will be limited to units and 
training entities eomprised of and integral to the training of a 
Carrier Strike Group (CSG) and/or Expeditionary Strike Group 
(ESG). 

Cyber Domain 
(non-foeus) 

The webfires eoneept and Training System will rely heavily on 
the ability to share information in eyber domain. The team’s 
foeus is to develop a training arehiteeture that eonsiders eyber 
implieations and information seeurity; however, the aetual 
ereation of information safeguards would be outside the seope 
of the researeh. 


D. DEFINITIONS 

The following definitions aid the reader in the understanding of some key terms in 
this report. 

I. Cost Effective 

Most definitions of eost effeetiveness revolve around some variation of aehieving 
the highest (or desired) quality for the lowest eost. Of eourse, the terms “desired value” 
and “low eost” ean have various interpretations aeross individuals, situations, and 
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applications. Therefore, cost effectiveness is an especially vague term that can take on 
several different meanings depending on the context, and it is more specifically defined 
relative to this project. 

Whatever method one might use to determine cost effectiveness, it generally 
encompasses a multi-faceted comparison of costs and performance. For example, cost 
effectiveness can be related to the cost of a project through the total allowed budget. 
Using this example, a solution must cost at or below budget to be considered cost 
effective. Another method to determine cost effectiveness is more qualitative, such as 
how a proposed solution compares to the current method of doing business, or how a 
proposed solution compares to other alternative solutions in a solution space. 

For this capstone project, a specific budget is not officially available, and a lack of 
comparisons to an allowed budget will not be a constraint in determining whether a 
solution is cost effective. Ideally, during the Analysis-of-Alternatives phase, a 
comparison of the costs and training value for each alternative would be plotted using the 
Cost as Independent Variable analysis technique. From this plot, the team would be able 
to determine a cost efficiency frontier to aid in determining which solutions are the most 
cost effective. Due to the classified nature of the webfires system and high end combat 
systems simulators, however, specific cost estimates were unattainable for this project. 
Additionally, other cost concerns should be factored into high-risk applications such as 
military operations. One particular cost concern is the cost associated with failure. 
Inadequacies in training can have high costs associated with them, particularly when 
these training inadequacies result in a loss of multiple units or lives. Even if inadequate 
training does not lead to the loss of units or lives, there are other, less quantifiable costs, 
such as degraded mission accomplishment or longer response time in the battlespace. 

Due to the complexity of the webfires technology, the inability to obtain cost 
estimates for high-end combat simulation systems, and the cost uncertainties associated 
with training inadequacies, the team has decided not to provide specific monetary values 
for cost effectiveness. This does not mean the need to be cost effective was dismissed 
when developing a training architecture. Though no quantitative cost effectiveness 
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argument is presented, the goal of a qualitative cost effective training architecture 
remained a focus throughout the project. 

Some qualitative cost effectiveness can be assumed in that it is desirable for the 
proposed solution to integrate into the existing training structure delineated in the 
Optimized Fleet Response Plan (OFRP). It is desirable that the proposed solution 
incorporate existing training facilities and training networks where feasible, thereby 
reducing the costs associated with building an entirely new training network. Finally, as 
simulation technology improves, training facilities will be able to simulate combat 
scenarios with greater fidelity. In some respects, current simulations can achieve a higher 
fidelity than is achievable in live exercises, particularly when simulating enemy tactics 
and weaponry such as missile profiles. 

There is potential for large cost savings by not sending an entire strike group 
underway to conduct a training exercise and instead conducting simulated combat 
scenarios while in port or at a training facility. Nevertheless, the ability to save money by 
training pier-side instead of underway does not imply that all underway training should 
be replaced with in-port training for the sake of cost effectiveness. 

2. Webfires 

The U.S. Navy has traditionally engaged enemy targets utilizing a linear kill chain 
process. This structure of attack, as described by Admiral Greenert, consists of four steps 
and is pictured in Figure 6: 

1. Find the target. 

2. Determine target’s location, course, and speed. 

3. Communicate that information coherently to the platform launching the 

weapon. 

4. Launch the attack using anything from a kinetic weapon to 
electromagnetic systems to cyber. (Greenert 2013) 

This integrated attack profile has a number of flaws. Any disruption within the 
four-step process will render the attack incomplete. For this reason, the process is 
commonly named a kill chain, as any removed link will break the chain. As our efforts 
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abroad work to exploit these weaknesses in adversarial weapon systems, it would be 
naive to assume the enemy is not trying to do the same to our weapon systems. The kill 
chain process now expands beyond the battlefield into the cyber domain, and requires 
significant investment in the area (Hutchins, Cloppert and Amin 2017). 



Adapted from Greenert (2013). 


Figure 6. Traditional Kill Chain Approach. 


To combat the enemy’s attempts to disrupt our kill chain process, and to expand 
the Navy’s offensive command and control (C2) capabilities, the DOD has invested 
heavily into integrated fires concepts, such as kill-webs. As described by Rear Admiral 
Manazir in 2016: 

The Navy has many effective kill chains —a sensor that provides targeting 
data to a platform that can then launch a weapon against a target—^in the 
air, ground, surface and undersea domains. The service has even made 
progress netting together some of these kill chains within a single domain, 
bringing together airplanes that rely on different communications 
waveforms and were not built to be interoperable, such as a recent effort to 
bring the F-35 Joint Strike Fighter and its unique Multifunction Advanced 
Data Link (MADL) communications into the Naval Integrated Fire 
Control-Counter Air (NIFC-CA) architecture. 

Now, these kill chains need to be strung together to create a cross-domain 
kill web, enabling any plane or any ship to pull information from whatever 
sensor happens to have relevant data, regardless of domain. 
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Figure 7 depicts Admiral Manazir’s concept for networked warfare and is used as 
the basic concept for webfires in this report. This webfires Operational View (OV-1) 
provides a standard DOD Architecture Framework (DoDAF), or basic engineering view 
of the system of systems architecture behind kill webs and the precursor system to 
webfires. Traditionally, each unit would operate independently, only utilizing onboard 
sensors and weapons. For example, the F-35 pictured at the top of the figure would utilize 
a kill chain that would find the target using onboard radars or cameras. Next, the onboard 
computer would calculate the onboard missiles launch profile. The pilot would launch the 
missile once instructed to do so. 



Adapted from Manazir (2016). 
Figure 7. Networked Warfare. 


Now each step in the engagement sequence, utilizing a kill web, would include 
additional sensors or weapons that give the best situational awareness or tactical ability to 
strike the target. For example, the destroyer shown in Figure 7 could utilize the over-the- 
horizon radar capability of the F-35 for targeting information and launch an offensive 
weapon against a threat that would otherwise be impossible for the destroyer to detect. 

One example of kill webs currently under advanced development for the carrier 
strike group is the Naval Integrated Fire Control - Counter Air (NIFC-CA). Although the 
technical aspects of the program are classified, in general, NIFC-CA provides a 
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situational awareness and extended-range cooperative targeting capability currently 
unavailable to the strike group. Another possible use of the NIFC-CA concept would be 
to expand the scenario depicted in Figure 7, where an airborne unit identifies, tracks, and 
targets an incoming missile for the surface ship. The surface ship then fires a defensive 
weapon utilizing the airborne unit’s targeting information to defeat the threat. A different 
scenario would be to use the airborne unit’s targeting information to launch an offensive 
weapon instead. These scenarios are shown in Figure 8. 


NIFC-CA From The Sea 





Adapted from Manazir (2016). 


Figure 8. NIFC-CA Scenarios. 


Rear Admiral Manazir has stated “every unit within the carrier strike group—in 
the air, on the surface, or under water—would be networked through a series of existing 
and planned datalinks so the carrier strike group commander has as clear a picture as 
possible of the battle-space” (Majumdar and LaGrone 2014). Each unit within the strike 
group has a unique role in a kill web. Each unit acts as a communication stepping stone 
for other units; this is accomplished through the proper utilization of a series of 
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waveforms. The current datalinks associated with high-bandwidth communication are 
displayed in Figure 9. 


TINT—the TTNT is long-range, low latency, high 
throughput data-link that will link together the 
critical nodes ol NIFC-CA. These include the 
E-2D, carrier, UCLASS and possibly the EA-18G. 


Link-1 &—Llnk16 is the standard data-link 
used by NATO. The Super Hornet will be 
communicate via this data-link since It does 
not need the data throughput levels of some 
ol the other aircraft such as the E-2D. 


Link-16/CMN-4—(his advanced version of 
Link-16 Is a potential alternative to TTNT on the 
Growler. Basically, it is four Llnk-16 systems 
running concurrently. 


Advanced Tactical Data-link—The F-35C will 
need a long-range, low-probability ol Intercept, 
jam-resistant data-link to relay its targeting data 
back to the E-20. Lockheed Martin is working on 
the capability for the jet’s Block IV configuration. 


Adapted from Majumdar and LaGrone (2014). 
Figure 9. Webfires Datalinks. 


3. High-Velocity Learning 

To continue to meet the commitments of the nation at an affordable price-point, 
the U.S. Navy must adjust its ability to learn and train to the evolving maritime security 
environment. It must adopt more innovative and intuitive learning models in order to 
maintain a fleet ready to operate, fight, and win decisively. As described in the CNO’s 
vision (Richardson 2016), to achieve high-velocity learning the U.S. Navy will: 

Apply the best concepts, techniques and technologies to accelerate 
learning as individuals, teams and organizations. Clearly know the 
objective and the theoretical limits of performance—set aspirational goals. 

Begin problem definition by studying history—do not relearn old lessons. 

Start by seeing what you can accomplish without additional resources. 

During execution, conduct routine and rigorous self-assessment. Adapt 
processes to be inherently receptive to innovation and creativity. 

1. Implement individual, team, and organizational best practices to 
inculcate high-velocity learning as a matter of routine. 

2. Expand the use of learning-centered technologies, simulators, online 
gaming, analytics, and other tools as a means to bring in creativity, 
operational agility and insight. 
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3. Optimize the Navy intellectual enterprise to maximize combat 
effectiveness and efficiency. Reinvigorate an assessment culture and 
processes. 

4. Understand the lessons of history so as not to relearn them. (2016, 7) 

Traditionally, the U.S. Navy is a highly structured institution with deep routed 
learning and training habits. “Most organizations are hindered by a structural problem: 
they manage their functions individually, not as steps in a well-integrated process. Each 
function does its job and somehow the whole thing comes together—except when it 
doesn’t” (Spear 2009, 357). 

High-velocity learning allows for better management of individual functions as 
they apply to the overall operation. Within the webfires concept, utilizing a high-velocity 
learning approach can better ensure sailors receive relevant and accurate knowledge 
throughout their individual and integrated training. This approach not only increases a 
sailor’s likelihood of being successful, but also increases the individual’s opportunity to 
learn. A model of the high-velocity learning process is summarized by Spear (2009) 
below and illustrated in Figure 10. 

Rather than letting each experience be either a success or a failure—but in 
neither case improving anyone’s chance of success on the next try [see 
Figure 9-1 ]—every experience is designed to increase the likelihood of 
success on the next try as knowledge and know-how accumulate [see 
Figure 9-2]. (118) 
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Figure 9-1 Succeed or fail 
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Figure 9-2 Succeed or learn to succeed 
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Source: Spear (2009). 
Figure 10. Likelihood of Success. 


Technology continues to develop at an exponentially faster rate; the currently 
outdated and rigorously structured learning model places sailors at a severe disadvantage 
in the operational environment. It is vital to mission success that equal importance is 
applied toward both developing the technical competency to perform various functions 
and the way that watch standers, watch teams, and technologies contribute to the 
operation of which they are a part. 

Highlighted in the early parts of the essay A Naturalistic Study of Insight, two 
efforts that can enhance human performance during high-velocity learning include 
reducing the number of mistakes and by increasing insights (Klein and Jarosz 2011). 
Many examples illustrate the bureaucratic and systemic lop-sided focus on the first effort 
over the second. According to Klein and Jarosz, the complaint that typically emerges 
from this imbalance centers on students’ failure to gain problem-solving insights due to 
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limited time, resources, and attention caused by the undue emphasis on reducing mistakes 

( 2011 ). 


4. Types of Training 

The Navy, as a whole, conducts many different types of training. For the purpose 
of this report, training is divided into three essential types: individual, unit, and multi-unit 
training. 


a. Individual Training 

Individual training is training that the Navy provides officers and sailors to 
prepare them to perform their specific occupational duties and attain their initial 
qualifications. This type of training focuses on the individual and can consist of 
classroom instruction, simulator time, or other forms of occupational training. 

b. Unit Training 

Unit training is the type of training that units perform as a whole to train their 
watch teams and sailors to work together to perform missions that a unit would be 
expected to perform. This training focuses more on team performance and less on 
individuals. 


c. Multi-Unit Training 

Multi-unit training is the type of training that focuses on units being able to 
perform missions with other units. The number of units involved in this training can 
range from as few as two (such as a surface ship conducting an anti-submarine warfare 
mission with a helicopter) to a full-scale strike-group exercise comprised of an air wing, 
multiple surface ships, submarines, or various combinations of such assets. 
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III. NEEDS ANALYSIS 


A. STAKEHOLDER ANALYSIS 

Stakeholder analysis is a tool to help the systems engineer better understand the 
problem at hand. Primary reasons for conducting stakeholder analysis include: to identify 
the people and organizations relevant to the problem, and to determine their needs, wants, 
and desires with respect to the project outcome. A secondary purpose is to start 
identifying critical assumptions and constraints on the problem. At the conclusion of this 
analysis, the systems engineer should have a better understanding of the real problem at 
hand. This analysis is derived in the form of a revised problem statement. 

The revised problem statement clearly outlines the true underlying needs of the 
client. Solving the revised problem statement is the objective that the proposed design 
architecture strives to obtain. This is the critical point on which the rest of the solution is 
built. To develop a satisfactory problem statement for the client, the systems engineer 
must conduct the stakeholder analysis properly. Failure to identify the correct problem or 
failure to identify the correct needs from the stakeholders could result in delivering the 
client a solution to the wrong problem as well as wasted resources along the way. The 
typical steps involved in stakeholder analysis are described in the following paragraphs. 

(1) Identify the Problem 

An initial problem statement is usually provided to the systems engineer by the 
client. The initial problem statement received from the client, however, is often vague or 
under-developed. Often clients do not know what it is that they really want or need. This 
can be expected because clients do not perform their own needs analysis, do not talk to 
the other stakeholders involved, and often do not know what feasible solutions exist. That 
is why the client seeks the expertise of someone familiar with these processes: the 
systems engineer. It is up to the engineer to identify and define the root problem. 
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(2) Identify Relevant Stakeholders 

Once the initial problem is identified, its definition will need to be refined. While 
the systems engineer may be an expert in the system design process, he or she is usually 
not an expert in the content area of the specific problem. For this reason, individuals with 
expertise in the subject matter related to the problem are often included as stakeholders. 

The name stakeholder comes from the vested interest or personal stake these 
groups or people have in the problem or its solution. Stakeholders are typically classified 
into one of several categories: clients, sponsors, decision makers, users, and analysts. It is 
the systems engineer’s task to identify likely stakeholders so that they may be contacted 
to provide some additional insight into the requirements and needs that the solution must 
address. 

(3) Develop a List of Questions or Desired Information and Conduct Research 
on the Problem 

Stakeholders do not always know what they want the solution to be, or what 
solutions are even feasible. It is the task of the systems engineer to research the problem 
and determine what additional information is needed from the relevant stakeholders to 
scope the problem space and generate an actionable requirements list. 

(4) Conduct Interviews 

After identifying who the stakeholders are, and developing questions to determine 
their needs, wants, and desires as they pertain to the problem at hand, the next major step 
is to collect information from the stakeholders. This is done by contacting the 
stakeholders directly to receive their inputs into the problem and what they might like to 
see in a solution. This stakeholder input helps to identify the “gap” between the current 
situation and the desired situation, where the “gap” represents the true needs of the 
solution. 

(5) Consolidate Information Gained 

Individual stakeholders do not always have the same needs as other stakeholders. 
Specifically, the end user may have different needs from the client providing the initial 
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problem, or even the sponsor paying for the solution. Stakeholder analysis provides a 
method for compromise between the needs of multiple stakeholders. This is achieved 
when the information from all of the stakeholders is obtained and consolidated into one 
needs statement. 

(6) Iterate as Necessary 

It is highly unlikely that all of the required information will be obtained in the 
first phase of stakeholder research. It is likely new questions will continue to arise 
throughout the project. Stakeholder analysis is conducted as an iterative process. As new 
information from the stakeholders is gathered, this information is then added to the 
requirements generation process. 

B. STAKEHOLDER IDENTIFICATION 

As part of any successful systems engineering project, requirements must be 
harvested, analyzed, and subsequently met by the proposed system; the key engagement 
must be with, and for, the stakeholders. In addition to the primary stakeholder, OPNAV 
N9I, the team identified key stakeholders to interview within two primary geographical 
areas: Fallon, NV, and San Diego, CA. During one of NFS’s thesis and research weeks 
(March 2017), the team conducted site visits to the commands shown in Table 6. The 
commands identified represent the points-of-view necessary for a majority of the 
stakeholder requirements. 


Table 6. Interviewed Stakeholders 


Command 

Location 

Naval Aviation Warfighting 

Development Center (NAWDC) 

Fallon, NV 

Tactical Training Group, Pacific (TTGP) 

San Diego, CA 

Naval Surface and Mine Warfighting 
Development Center (SMWDC) 

San Diego, CA 

Expeditionary Warfare Training Group, 
Pacific (EWTGPAC) 

San Diego, CA 

Third Elect (COMTHIRDEEEET) 

San Diego, CA 

Commander, Naval Surface Eorces 

Pacific (COMNAVSUREPAC) 

San Diego, CA 
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Per NPS protocol, it is imperative that all questions to stakeholders first receive 
approval by an Institutional Review Board (IRB) to ensure the project is the intended 
focus and there is no inadvertent human research without the proper procedures in place. 
The team generated a list of stakeholder questions and submitted them to the IRB and 
SEA Chair prior to visiting. The questions were determined to not contain human subject 
research in any form. A list of the IRB approved questions and associated IRB 
documentation appear in Appendix E. 

1. Naval Air Warfare Development Center 

The primary mission of NAWDC is to provide aviation flight training, academic 
instruction, and operational and intelligence support for all aviation platforms throughout 
the Navy (CNIC 2017). Along with development and updating of Tactics, Techniques, 
and Procedures (TTPs) for aviation mission areas, NAWDC provides subject matter 
experts (SMEs) to major commands that support the OERP training continuum 
throughout the world (2017). 

The team noted the following significant observations from NAWDC: 

• NAWDC engages in integrated training primarily through established 
systems such as NIEC-CA. This system has had significant impact on the 
operations on the tactical and operational level. 

• Debriefing of training events conducted at NAWDC is accomplished in 
one room, with all players in a face-to-face environment. This tends to 
provide positive training, with all assets able to follow thought processes 
and resulting actions that occurred and is facilitated by local SMEs. The 
environment especially allows for common references, increased synergy, 
and creative/unique perspectives from various platforms. Improvements 
needed include increased man-machine interfaces, better communication 
systems, higher fidelity, and inclusion of key warfighters involved in 
tactical decisions. 

• Intelligence updates lag due to lack of direct input and resultant changes to 
the TTPs. This is primarily due to security concerns and human interaction 
required to determine importance and effectiveness. 

• Recorded data analysis lags behind the real-time tactical engagements 
resulting in unknown effectiveness. During training, operators must use 
estimates and models to evaluate performance. 
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• There is a significant effort to integrate real and simulated world, such as 
with Aegis Air Defense with aircraft, but there is a concern with security 
and data integrity. 

• There is currently no training timeline that unifies the phases of the OFRP 
across multiple domains nor an established command responsibility for 
integrated training requirements. 

• Geographically, Fallon, NV, is secluded from the major fleet 
concentrations, and only a limited number of personnel are currently 
available to be sent from commands for extended periods of integrated 
training. 

2. Tactical Training Group, Pacific 

The Tactical Training Group, Pacific (TTGP), along with its East-coast 
counterpart. Tactical Training Group, Atlantic (TTGL), provides tactical training in 
support of the OFRP training, specifically for and within the numbered fleets (U.S. Navy 
2017b). They establish and present curricula, interactive simulations, and innovative 
feedback for customers (2017b). They coordinate with Commander, Carrier Strike Group 
Fifteen (CSG-15) for underway training. 

The team noted the following significant observations from TTGP: 

• Live Virtual Constructive (LVC) training has many different 
interpretations. There is little standardization for what constitutes an LVC 
training event within tactical syllabi; scenarios take up to a full year to 
develop. 

• Weapons and Tactics Instructors (WTI) as seen in the aviation community 
has become a “best-practice” model that surface vessels are implementing. 

• Networks such as the Navy Continuous Training Environment and Joint 
Semi-Automatic Lorces (JSAL) provide more information and quicker 
interaction for warfighters to recognize enemy/friendly forces and engage 
more effectively, but are currently platform limited by the high cost of 
implementation at a tactical level. Red force players are currently trained 
personnel, with no AI component. 

• Licet Synthetic Training (LST) requires robust communication networks 
and bandwidth and currently is limited to CONUS locations. 

• Commands interested in TTGP training lack resources and people to send 
temporarily for on-site training, and they currently are limited in 
connecting trainers at tactical locations. 
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3. Surface and Mine Warfare Development Center 

The Surface and Mine Warfare Development Center (SMWDC) concentrates on 
the surface warfare community’s tactical training in six core areas, including Amphibious 
Warfare, Air Warfare, Ballistic Missile Defense Mine Warfare, Missions of State, and 
Surface/Anti-submarine Warfare (SMWDC 2017). It supports training individuals in the 
OFRP by developing, improving, and integrating surface warfare doctrine. 

The team noted the following significant observations from SMWDC: 

• Surface community is currently attempting standardization through the use 
of the Surface Warfare Combat Training Continuum and Surface Warfare 
Advanced Tactical Training programs. 

• Adaptation to other communities’ best practices has worked and is 
currently underway in the surface community to establish a cadre of 
recognized tactical SMEs for standardized warfare training. 

4. Expeditionary Warfare Training Group 

The Expeditionary Warfare Training Group (EWTG) conducts mostly classroom¬ 
centric training and instruction to support amphibious expeditionary warfare operations 
that support the U.S. Navy’s mission of projection of power from the sea. In addition to 
construction and modifications of TTPs, EWTG employs SMEs in the realm of modeling 
and simulation providing realistic synthetic training (U.S. Navy 2017a). 

The team noted the following significant observations from EWTG: 

• Differing infrastructure and communication networks, especially between 
the United States Marine Corps (USMC) and USN units, complicates 
coordination between existing systems. Eor example, this has been seen in 
Marine Air-Ground Task Eorce Tactical Warfare Simulation (MTWS) and 
JSAE. 

• Significant resources are lacking, especially for personnel considering 
career timing and availability for onsite training (for both student and 
instructor roles). Infrastructure and funding does not exist for the 
establishment of simulators to be placed with all units that could benefit 
from them. 

• The acquisition process does not integrate with other projects that are 
either already established or in the process of being developed. 
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• Senior leadership misinterprets the ability to integrate current commercial 
programs into military training, as computer technology and infrastructure 
in military systems are severely lacking the resources to do so; there is a 
search for solutions that lack requirements. 

• Integration between USN and USMC forces has suffered due to lack of 
USN personnel billeted to the command. 

5. Commander, U.S. Third Fleet 

While one of five numbered fleets, Commander, U.S. Third Fleet 
(COMTHIRDFLT) is responsible for maintenance, operations, and training of the Pacific 
Fleet and seaward approaches to the western United States (Global Security 2017b). 
Additionally, as a Joint Task Force commander, COMTHIRDFLT is directly affected by 
and responsible for integrated tactical training in conjunction with each subordinate 
command’s OFRP cycle (2017b). 

The team noted the following significant observations from COMTHIRDFLT: 

• Management of individual projected rotation date either coming or leaving 
the command is essential for assuring readiness or maintaining qualified 
warfighters. 

• NEC codes do not allow for retraining on new and improved technologies, 
requiring more on-the-job training, less effective learning, and an 
imbalance of practical knowledge within and between watch teams. 

• NIFC-CA is operational only in a Live environment and networks such as 
Baseline 9 do not integrate in FST environments. Significant Information 
Assurance (lA) problems exist between broadcasted and implemented 
tactics and established networks. 

• Costs to send vessels underway to train are prohibitive. There would be 
significant cost savings in establishing quality underway training without 
leaving the pier. 

• Objectives for training are needed, no matter what phase of the OFRP is 
being executed. 

6. Commander, Naval Surface Force, U.S. Pacific Fleet 

Commander, Naval Surface Force, U.S. Pacific Fleet (COMNAVSURFPAC) is 
the primary entity ensuring that surface forces operating in the Pacific and Indian Oceans 
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have completed all training, maintenance, and manning requirements to operate in joint 
and cooperative efforts to support the Navy’s global missions (Global Security 2017a). 
Additionally, within the command’s hierarchy is the Distributed Lethality Task 
Force—the U.S. Navy’s concept of increasing offensive capabilities of ships while 
spreading the units’ formation in a synergistic fashion (Rowden, Gumataotao and Fanta 
2015). 

The team noted the following significant observations from 
COMNAVSURFPAC: 

• Current communication networks are not real time and require specific 
encoding/decoding that is not compatible with budding technologies and 
threats. This results in an integration and interoperability problem. 

• As newer technology solves these issues or webfires concepts advance, a 
central training network/facility will provide benefits. 

• A recognized lack of in-person debrief from multiple platforms is 
acknowledged. There is a need to adopt SMWDC’s Plan, Brief, Execute, 
Debrief (PBED) cycle for all integrated training evolutions. 

• Significant procurement and acquisition problems result in integration 
concerns. 

• It is not necessary to reinvent what actually exists; foreign navies have 
figured out certain tools to facilitate the PBED process. 

• Tactical integration is not being addressed above the Type Commander 
(TYCOM) level, but remains a requirement. 


36 



IV. CURRENT TRAINING PROCESS 


Training sailors and Marines to perform tasks in support of CSG or ESG missions 
is a complex assignment. Considerable repetition is needed for personnel to reach the 
required individual training level for combat effectiveness and to support the unit’s 
missions. Additionally, considerable time must be set aside for entire training units to 
work with other units that support larger integrated and complex operations. To address 
the demands placed upon the force, the Navy has created a revised OFRP, which provides 
“continuous availability of manned, maintained, equipped, and trained Navy forces 
capable of surging forward on short notice while also maintaining long-term 
sustainability of the force” (Howard 2014). This chapter discusses how the Navy 
currently trains individuals, in addition to how the Navy trains and manages the Fleet in 
order to provide a “flexible force to respond to combatant commander [needs]” (Howard 
2014). 

A. INDIVIDUAL TRAINING 

The following sections detail how individual sailors and officers are trained to 
operate and maintain combat systems in each community. For the purpose of this section, 
only personnel with responsibilities that relate to a submarine, aircraft, or ship’s combat 
systems are examined. 

Regardless of the warfare area or community, officer training focuses on the .skills 
and knowledge that officers must have, whereas enlisted training focuses on the skills and 
knowledge that sailors within various ratings must possess, and combined training 
focuses on watch team training. 

I. Undersea Warfare Domain 

Naval officers who volunteer for the Submarine Force must go through the 
Nuclear Power Training Course and the Submarine Officer Basic Course prior to arrival 
at their first submarine command. Nuclear power training focuses on the skills that an 
officer must possess in order to maintain and operate the nuclear reactor onboard 
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submarines. The Submarine Officer Basic Course focuses on the knowledge and 
leadership skills that an officer must possess for basic submarine navigation, contact 
management, and warfare tactics. 

Once officers complete both training courses, they are sent to their first command. 
While stationed there, officers must go through a warfare qualification process. This 
qualification process ends with being qualified in three positions: Surface Officer of the 
Deck, Submerged Officer of the Deck, and Qualified Submarines, or “earning the 
dolphins.” During this qualification process, officers must demonstrate the ability to 
conduct contact management, submarine navigation, and warfare tactics in a real world 
environment. After an officer has completed the initial sea tour he or she must go to the 
Submarine Officer Advanced Course prior to returning to the fleet. This course expands 
the knowledge and skills that an officer learned during that first sea tour. During this 
phase of training there is a larger focus on warfare skills and tactics. 

Following boot camp, enlisted sailors are sent to Groton, CT, for Basic Submarine 
School where they learn basic damage-control and firefighting skills. Once they have 
completed Basic Submarine School sailors are assigned their rate. For the purpose of this 
report, it is one of the combat systems rates, such as Sonar or Fire Control Technician. 
Both types of technicians are responsible for operating and maintaining the equipment 
that is associated with submarine weapons systems. Once they have been selected for 
their rate, these sailors then learn the basic skills and knowledge necessary to operate and 
maintain a submarine’s weapons systems. 

Once these sailors have completed their initial training they are sent to their first 
sea command. While at their first command, these sailors go through a qualification 
process that allows them to learn, in an operational environment, the skills required for 
them to operate the weapon systems. 

Officers and enlisted sailors must be evaluated routinely to ensure that they are 
maintaining the necessary skills and knowledge to operate the submarine effectively. This 
currency is maintained through the use of proficiency training, examinations, and watch 
evaluations conducted by superiors. 
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Both the officer and enlisted training pipelines teach sailors the basic knowledge 
and skills necessary to employ a submarine in a tactical environment. These pipelines do 
not focus on combined team or multi-unit training. Each submarine has multiple watch 
teams composed of officers and enlisted sailors who must work together as a team to 
tactically employ the ship. To train these watch teams, units use a variety of techniques 
and equipment. These include walk-throughs, training simulator time, simulated threats 
using onboard systems, and practice scenarios at sea. 

Type commanders routinely use Tactical Readiness Examination Teams to 
evaluate a ship’s training level. More specifically, these teams evaluate the ability of a 
submarine to conduct combat operations. Additionally, submarines frequently train with 
Tactical Readiness Examination personnel aboard in order to evaluate the crew and 
provide recommendations in areas where they need improvement. 

2. Air Warfare Domain 

The naval aviation career path is only offered to commissioned officers and 
provides an opportunity to learn to fly while gaining the relevant knowledge required to 
operate military aircraft in combat operations. This training is not envisioned to include 
enlisted air warfare rates. A commissioned officer begins the path to becoming a naval 
aviator in Pensacola, EE, where Student Naval Aviators (SNA) enroll in introductory 
flight screening (lES). lES introduces the SNAs to a civilian flight program where they 
learn the basics of flying. Each student is afforded 25 hours of single-engine flight time 
with a minimum of two solo flights (without an instructor) in a civilian trainer aircraft. 
After successfully completing the requisite flight hours and a Eederal Aviation Authority 
private-pilot knowledge test, the SNA transitions to Aviation Preflight Indoctrination, 
also located in Pensacola. 

Aviation Preflight Indoctrination consists of six weeks of classroom instruction 
focused on aerodynamics, aircraft systems, meteorology, air navigation, and flight rules 
and regulations. After the classroom portion, SNAs are provided two weeks of practical 
training that include land survival, first-aid, physiology, and water survival topics. 
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Shortly after completing Aviation Preflight Indoctrination, SNAs are enrolled in 
primary flight training. SNAs will learn to fly the Navy’s Beechcraft T-6 Texan II at 
either Naval Air Station (NAS) Whiting Field, FL, or NAS Corpus Christi, TX. 

Primary flight training reinforces basic flight skills learned at IFS while applying 
additional rigorous military flight standards. Ground school is offered before any student 
steps into the T-6 Texan II. Basic knowledge, including knowledge of aircraft systems, 
local flight rules, and emergency procedures, are taught and tested. Next, the Contact 
phase introduces the SNAs to their first of many military training flights. The basics of 
takeoffs, landings, stalls, and spins are introduced and practiced. The remainder of flight 
time is split among the basic instrument phase, aerobatics phase, formation phase, radio 
instrument navigation phase, night flight phase, and visual navigation. 

After successfully completing primary flight training, an SNA graduate will select 
from a number of flight platforms, such as strike aircraft, E-2/C-2, E-6B mercury, 
maritime patrol, or helicopters. Each platform consists of a platform-specific flight 
syllabus performed during advanced flight training. 

Strike platform is designed to train future Navy EA-18 C/D, EA-18E/E, EA-18G 
Growler, and E-35C Eightning II pilots. The students will fly the T-45C and gain further 
experience with basic flight skills and additional air combat maneuvering (ACM), low- 
level navigation, tactical formation flying (TACEORM), and carrier qualifications (CQ). 

E-2/C-2 platform is designed to provide future E-2/C-2 pilots dual engine 
experience not obtained in primary flight training. The aircraft utilized is a military 
variant of the Beechcraft King Air (T-44) 

Rotary-wing platform is designed to take a newly minted fixed-wing pilot and 
impart the fine art of rotary-wing flight. A classically trained helicopter pilot teaches 
these skills to students flying the mighty TH-57 Sea Ranger. The SNA will learn the 
unique skills required to fly a helicopter within a relatively short 100 hours of flight time. 
A few of the training phases include helicopter familiarization, tactics, low-level 
navigation, formation flight, night flight, and search and rescue. 
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After completing one of the advanced flight training curricula, the SNA will 
graduate to become a Naval Aviator, earning his or her Navy “Wings of Gold.” Naval 
aviators will transition to Fleet Replacement Squadrons where the skills and tactics 
required to operate fleet aircraft are learned. 

3. Surface Warfare Domain 

Currently the surface force primarily trains its officers via a combination of 
schoolhouses and at-sea exercises, with simulator experience as a rare occurrence. Prior 
to arriving to their first ship, a surface warfare officer (SWO) receives some introductory 
classroom training on ship systems and duties, but there is little to no focus on combat or 
tactics at this early stage. After completion of the first division officer tour at sea, a SWO 
is for more advanced schoolhouse training called Advanced Ship handling and Tactics, 
but ironically, there is little combat or tactical training involved in this schoolhouse 
training. At both introductory and Advanced Ship Handling and Tactics training, 
simulators are used to help train the junior SWOs, but these simulators predominantly 
focus on ship handling skills and bridge watch-standing coordination. If a SWO is 
fortunate enough to receive a billet into a combat watch-standing position for his or her 
second division officer tour, the SWO will likely go to a specialized school. There SWOs 
receive specific training for the watch station they are expected to qualify for and fill on 
the ship. At these schools, the training will finally focus on learning tactics. This is taught 
using a combination of classroom education and tactical simulations of combat scenarios. 

The next major milestone of a SWO is the department head (DH) tour. Here every 
SWO takes tactical responsibility while standing watches as a Tactical Action Officer 
(TAO) in charge of the ship’s Combat Information Center (CIC). In preparation for this, 
the future DH receives extensive training and simulations. Once onboard the ship, they 
receive more realistic training through underway exercises at sea. 

A similar training pipeline takes place for prospective commanding officers 
before they arrive at their next at-sea command. These senior SWOs will attend various 
schools to acquire the training necessary for commanding a ship, including a tactical 
simulator experience. 
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The process for enlisted combat watch stations is similar, with the exception of 
longer timelines at initial schools in order to learn their rates, and longer tours on any 
particular ship. The bulk of the training still takes place with classroom education at 
schoolhouses and real world exercises while underway at sea. Simulators are 
predominantly used only while pier-side. 

One element largely lacking from the current SWO training and enlisted pipelines 
is widespread use of tactical simulators, except for when conducted at various shore 
facilities prior to these personnel reporting to their next at-sea command. 

B. OPTIMIZED FLEET RESPONSE PLAN 

The focus of the OFRP is to “maintain, train, deploy, and sustain readiness when 
at home ... and yet to optimize that cycle, the Navy must align numerous ‘subordinate 
processes’ and balance goals of various naval communities, requiring a cross-community 
collaboration” (Eckstein 2016). By implementing this process, the fleet will “ultimately 
be better prepared to meet combatant commander needs without straining the ships, 
planes, and sailors” (Eckstein 2016). The OERP cycle consists of five phases: 

1. Maintenance 

2. Basic 

3. Integrated 

4. Advanced 

5. Sustainment 

These phases help focus the Navy’s activities and resources with the following 
lines of effort: “fleet response plan length, command and control (C2) alignment, 
manning and individual training, maintenance and modernization, logistics. Military 
Sealift Command (MSC) support, inspections, unit and advanced training, and 
operational and tactical headquarters training” (Howard 2014, 2). 

The following list is an excerpt from Admiral Howard’s OPNAVINST 3000.15A. 
By focusing the Navy’s resources and activities on these lines of effort, the OERP will 
help generate the following: 
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Predictable force generation cycles. 


OFRP cycle length that supports maintenance and training while 
maximizing employability. 

Consistent chain of command throughout OFRP. 

Right Sailor, right training, right time, in a sea-centric Navy. 

Continue rotational crewing and required manning at the beginning of the 
basic phase. 

Stable and predictable maintenance plan. 

Modernization that supports warfighting integration and interoperability. 

Parts, ordnance, and other transportation to support training and 
operations. 

Fully capable and modernized MSC ships available to support fleet 
combat and peacetime requirements. 

Consolidated and streamlined inspections, certifications, assessment, and 
visits. 

Forces trained to a single high-end, near peer standard. 

Tactical headquarters organization, capability, and capacity aligned with 
standardized maritime operations centers. (Howard 2014) 


1. OFRP Cycle 

The OFRP cycle is a 36-month cycle that begins in the maintenance phase. The 
maintenance phase is seven months long, followed by the basic and integrated, or 
advanced phase of seven months, and the sustainment and deployment phase of 22 
months. Each phase is discussed in detail. The OFRP is illustrated graphically in 
Figure 11. 
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Figure 11. OFRP Cycle. 


a. Maintenance Phase 

Typically, the maintenance phase is a 24-week availability with a 4-week post¬ 
availability shakedown, but it can be as long as 16 months (Howard 2014). As delineated 
in Admiral Howard’s OFRP, this phase focuses on major shipyard and depot-level 
repairs, upgrades, force reconstitution, and platform modernization. While performing 
maintenance, units must still focus on individual and team training in order to maintain a 
solid foundation of readiness (2014). 

b. Basic Phase 

The Basic Phase starts directly after a unit leaves the maintenance phase and 
typically lasts 6 months, though it can vary depending on the type of unit. According to 
the OPNAVINST 3000.15A: 

The basic phase focuses on development of unit core capabilities and 
skills through the completion of basic-level inspections, certifications, 
assessments and visits and training requirements as well as achieving 
required levels of personnel, equipment, supply, and ordnance readiness. 

Units and staffs that have completed the basic phase are ready for more 
complex integrated or advanced training events, or appropriate tasking 
[such as homeland security or humanitarian assistance and disaster relief 
operations]. (Howard 2014) 

Basic phase training focuses on a unit developing its core mission sets in 
preparation to move on to more advanced training that will require it to work with other 
units in an integrated environment such as within a CSG, ESG, air wing, or Surface 
Action Group. 
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c. Integrated Phase 


“The purpose of integrated phase training is to synthesize individual units and 
staffs into aggregated, coordinated strike groups (or other combined-arms forces) in a 
challenging, multi-dimensional threat, realistic warfare environment” (Howard 2014). 
During this phase, units are given time to complete required inspections, certifications, 
and multi-unit training (both in port and out to sea) against high-end near-peer threat 
conditions (Howard 2014). Upon completion of this phase units will be certified to 
deploy and qualified to perform the following missions and capabilities at a minimum: 

Proficiency in intelligence, surveillance, and reconnaissance, C2, air 
operations, maritime operations, information operations, power projection, 
ballistic missile defense, peacetime presence, amphibious operations, 
special operations forces support, combat search and rescue, mine warfare, 
sustainment and stability operations, and antiterrorism and force 
protection. (Howard 2014, 5) 

d. Advanced Phase 

The advanced phase is only for independent deploying forces that are not part of a 
CSG or ESG (2014). Like the integrated phase, this phase gives time to units to perform 
training, certification, and inspections. If these units are required to eventually aggregate 
into a CSG or ESG this phase can also provide integrated training, as necessary, as 
previously described. Once complete with this phase a unit will be certified to deploy 
(2014). 


e. Sustainment Phase 

The sustainment phase begins when a unit has completed basic or integrated 
training and ends when the unit returns to the maintenance phase (2014). During this 
phase, a unit can be deployed as a unit, multi-unit, or ESG/CSG in support of a 
combatant commander. During this phase, training aims to maintain a unit’s proficiency 
and readiness to deploy (2014). 
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2. Navy’s OFRP Organization 

As discussed earlier, the focus of the proposed WFTS is to develop a system that 
helps support basic, integrated, and sustainment training. To understand how the WFTS 
can do this, we need an understanding of the organization that supports these three 
phases. The following section examines the organizations (people, groups, units), the 
activities (tasks) they perform, and the operational items (information) that are passed 
between them. 


a. Figure Guidance 

In Figures 12 through 15, parallel lines represent the organizations involved in 
each phase of training. On each line, white boxes are used to represent activities (tasks) 
that each organization performs to support or provide training. The gray boxes show the 
inputs and outputs of information that operational activities share with other operational 
activities. Additionally, the figures also indicate a direction of flow. Parallel lines show 
that organizations are performing their set of operational activities congruently. The order 
of the operational activities shows that an organization may have to perform some 
activities before others. Finally, the arrows coming in and out of the grey boxes show 
what operational activities are producing and providing for other operational activities. 

b. OFRP Illustrations 

The following four figures provide an overview illustrating the complexity related 
to the conduct of sustainment, integrated, and basic training. These figures are not all 
inclusive of the detailed intricacies of the Navy’s organization, but are useful in showing 
the general organizations involved, the activities they perform, and the information they 
share in the training environment. 
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As shown in Figure 12, operational activities or tasks of providing training in each 
of the basic, integrated, and sustainment phases of the OFRP are conducted in parallel. 
Each one of the three tasks is broken down into sub-tasks or sub-operational activities. 



Figure 12. Operational Activity Overview 

Figure 13 depicts the operational activities that the TYCOM, Certification 
Programs, Fleet Level Training Facilities, and CSG/ESG Units perform to facilitate 
training during the basic phase of the OERP. The left side shows just the operational 
activities while the right side shows the inputs and outputs of the operational activities. 
Eor more details, see Appendix B, which lists the inputs and outputs of each operational 
activity along with the organization that performs that activity. 
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Figure 13. Basic Training Overview 
48 













Figure 14 depicts the operational activities that the Numbered Fleet Commander, 
Tactical Training Group, CSG/ESG Commander, Fleet Level Training Facilities, and 
CSG/ESG Units perform to facilitate training during the integrated phase of the OERP. 
The left side shows just the operational activities while the right side shows the inputs 
and outputs of the operational activities. Eor more details, see Appendix B, which lists 
the inputs and outputs of each operational activity along with the organization that 
performs that activity. 
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Figure 14. Integrated Training Overview 
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Figure 15 shows the operational activities that the Numbered Fleet Commander, 
CSG/ESG Commander, and CSG/ESG Units perform in order to facilitate training during 
the sustainment phase of the OERP. The left side shows just the operational activities 
while the right side shows the inputs and outputs of the operational activities. Eor more 
details, see Appendix B, which lists the inputs and outputs of each operational activity 
along with the organization that performs that activity. 
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Eigure 15. Sustainment Training Overview 
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V. GAP ANALYSIS 


Through research, interviews with stakeholders, and the development of a concept 
of operations for the WFTS, the team identified critical gaps in the Navy’s training 
system that will prevent the future warfighter from effectively and efficiently employing 
webfires. Identification of these gaps is critical in the systems engineering process 
because any proposed solution must address known gaps. Systems engineers can use the 
identified gaps to help develop capability requirements that a system must possess in 
order “to meet an organization’s role, functions, and missions in current or future 
operations” (Defense Acquisition University 2017). After capability gaps have been 
determined, the concept of operations (CONOPS) can be fully developed to describe how 
the future system will address these gaps. This CONOPS is useful to determine capability 
requirements that will then drive the rest of the system architecture that will be developed 
to address the defined gaps. 

A. IDENTIFIED GAPS 

“Gap Analysis is the comparison of actual performance with potential or desired 
performance; that is, the ‘current state’ the ‘desired future state’” (Emery 2017). The 
following paragraphs discuss each gap in detail to explain how the current system 
struggles in meeting a gap and why the gap is important to webfires training. The team 
discovered four major gaps during our research. Some of the major gaps have multiple 
factors, which are expanded upon to provide background and an understanding of the 
nature of the gap. 

I. Lack of Webfires Concept Training 

The development of the webfires concept necessitates the development of a 
webfires training system. No other current training systems meet the unique requirements 
for a highly integrated warfare system. Limited elements of the needed training have been 
implemented, including NIFA-CA located in Fallon, NV; however, no overall centralized 
solution has thus far been developed. 
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2. Lack of Multi-Unit Training Repetition to Support Additional 
Webfires Training Requirements 

The team considers the inability to perform quality repetitions as the most 
significant limitation to integrated training. Current training allocates limited time and 
resources during the integrated phase of training. While the traditional model is sufficient 
for today’s battlespace, the webfires construct relies heavily on integrated tactics that 
must be practiced and improved upon. A significant increase in resources, including 
funding and time, would provide a measureable increase in overall CSG/ESG 
performance. A number of identified factors also hinder the ability to perform multiple 
iterations of integrated training. Following is a detailed list of factors that contribute to 
this gap and the training architecture will address. 

a. Lack of Standardized Multi- Unit Scenarios for Training 

The current approach to integrated training relies on third-party shore-based 
training groups, such as TACTRAGRUPAC/LANT, to provide pre-programmed 
scenarios for use in the integrated environment. These scenarios are difficult and 
expensive to produce and stage, and are unable to be performed independent of these 
third-party organizations. This hinders training multiple CSG/ESG. Additionally, the 
range at which the training can be conducted is reduced due to the line-of-sight 
limitations of these radio-operated networks. Providing the CSG/ESG the ability to create 
and run their own training scenarios that focus on the specific threats in an area of 
responsibility (AOR) can greatly improve training quality and relevance. 

b. Lack of Communications Bandwidth between Ships and Simulators 

Currently, integrated training relies heavily on using real communications circuits 
to conduct training. The issue with this approach is that communications circuits are 
limited in bandwidth and are often prioritized for military operations, thus limiting time 
and resources for effective training. Additionally, units must periodically conduct routine 
maintenance on their communications systems, which can limit a unit’s capability to 
perform integrated training. 
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c. Lack of Resources at TTGs to Support Multiple Training Simulations 
Simultaneously 

Currently integrated training relies heavily on a central node (TTGP/L) to 
establish communication and simulation links to perform a controlled scenario. This 
reduces the frequency of training events and limits the warfighter’s ability to perform 
multiple repetitions to increase his or her proficiency. Increasing the physical data 
processing capability would not completely solve the issue. These facilities rely heavily 
on experts who are able to evaluate each unit’s performance and provide useful feedback. 
The facilities also lack the number of qualified personnel who would be required to 
conduct more of this type of training. 

3. Lack of Compatible Networks to Perform Multi-Unit Training 

The severely convoluted and complex mix of network types and responsible 
parties that exists today is incompatible for the integration required to run the WFTS. The 
issue is rooted in two primary areas: the lack of common information assurance (lA) 
regulations across services and acquisitions programs, and the lack of a physical and 
reliable network system to connect live units and simulator stations. 

a. Lack of Common lA Certifications to Integrate Data 

Training networks are developed to operate for a specific purpose, which is 
generally focused on serving the community that acquired it. Often times, however, little 
thought has been placed into integrating these training networks. The attempt to integrate 
the Navy’s training network with that of the Marine Corps is such an example. The major 
limitation is the lack of common lA certifications. The certifications designed to protect 
the data significantly hinder the ability to share data over different networks within the 
DOD. Other examples discovered during stakeholder interviews demonstrated that the 
ability to share data within the Navy’s own networks is often artificially reduced through 
complex and non-standard lA requirements. 
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b. Lack of Ability to Interface Units and Facilities/Simulators 

Current training facilities were designed only with their respective communities 
(i.e., helicopters, jets, destroyers, and cruisers) in mind, with little capability to interface 
with a different community. This obstacle is even more apparent in attempts to interface 
live units (i.e., deployed ships, flying aircraft) with simulators. Our research has shown 
very little capability exists to integrate these different training environments into a 
common scenario. To ensure the quality of training required to learn integrated tactics for 
employment of a webfires concept, these systems must be able to integrate seamlessly. 

4. Lack of a Quality Feedback Process 

At the end of any training event the students and instructors should gather 
together to replay the event and discuss the training in detail. Reviewing these details 
allows the students to recognize both the positive and negative decisions made and any 
possible future corrections. Conducting training without feedback detracts from the 
overall quality of training. Without the opportunity to review and correct mistakes in a 
timely manner, training quality and mission performance are negatively affected. 

a. Lack of Face-to-Face Debriefing by SMEs and Groups Conducting 
Multi-Unit Training 

The aviation community has recognized these benefits and adopted a robust 
feedback system. All involved pilots and instructors meet soon after each flight to review 
the training evolution. The use of available video and audio recording helps provide a 
clear picture of the events that took place. Additionally, instructors provide feedback 
directly to the students in an open forum to discuss any mistakes or confusion during the 
event. No one should walk away with any questions or confusion. This system, although 
beneficial, has not been adopted by all communities. However, the surface and sub¬ 
surface communities are beginning to implement various methods that attempt to model 
the aviation system with varying degrees of success. 
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b. Lack of Necessary Capability to Assess Webfires Training, Doctrine, and 
Procedures against a Near-Peer Threat 

Current training systems contain functionality to assess the progress and 
effectiveness of unit-level training. These tools focus on providing detailed analysis for a 
single platform type. This limited analysis consequently isolates information required for 
integrated analysis. Determining the fleet’s performance against future near-peer threats 
requires the ability to combine integrated performance results effectively to determine 
fleet tactical performance. 

c. Lack of Automated Data Processing for Expedited Evaluation of 
Training 

The current feedback process following a fleet exercise is painstakingly slow. 
Information processing times range from hours to weeks depending on the platform and 
event. The webfires training system must process results within an event timeline to 
produce desired training results effectively. 

B. LESSONS LEARNED 

To help identify the WFTS gaps, the team analyzed past and current training 
systems installed on ships and at training facilities to gain more insights. Based on these 
complex training systems, the team was able to identify some of the valuable lessons 
learned. 

First, it takes a long time to properly design and install the training system 
onboard a ship. This is due to several reasons. One reason is that procedures are difficult 
to follow and complete properly. The other reason is the sailor’s lack of training in 
installing the equipment. Second, it takes a long time to troubleshoot the training systems. 
Due to the complex nature of the training system hardware and software, the maintainers 
must spend considerable time troubleshooting and repairing the systems. Third, there is 
lack of interfaces between training facilities. Various contractors have designed and built 
the training systems, often making these systems unable to communicate with each other 
for an integrated training event. Finally, there are many connectivity issues between ships 
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and training facilities. This is due to both the poor reliability of pier connections and a 
ship’s scarcity of bandwidth. 


58 



VI. CONCEPT OF OPERATIONS 


This chapter describes the process by which the proposed WFTS will operate. 
After defining the process, the chapter presents short illustrative stories to help the reader 
put the operations into context. 

A. DEFINITION 

According to the website, AcqNotes.com (2017d), a resource archive for 
acquisitions and engineering professionals working in the DOD environment, a CONOPS 
is defined as: 

CONOPS is used to examine current and new and/or proposed capabilities 
required to solve a current or emerging problem. It describes how a system 
will be used from the viewpoints of its various stakeholders. This provides 
a bridge between the often vague capabilities that a project begins with 
and the specific technical requirements needed to make is successful. A 
CONOPS is a useful tool that helps the user community write/refine 
[capability requirements and functional requirements that a system must 
have in order to close the identified capability gaps and meet the intended 
goals of a system]. 

In conjunction with vignettes (short stories describing the system solving the 
problem), the CONOPS helps designers develop final capability requirements, system 
requirements, operational activities, and functions that the system must perform in order 
to fill the capability gaps that were previously identified. Once these steps have been 
completed, an analysis of alternatives is conducted to determine the solution that will best 
fulfill the requirements and address the capability gaps. From the AcqNotes website, the 
purpose and objectives of a CONOPS are summarized below. 

I. Purpose 

• Aid in getting stakeholder agreement on how the system will be operated. 

• Help show high-level system concepts and aid in their justifications. 

• Help define high-level requirements. 

• Define the environment in which the system will operate. 
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• Help in the system validation process. 

2. Objectives 

• The goals and objectives of the system. 

• Constraints affecting the system. 

• Organizations and interactions among participants. 

This chapter begins by introducing the CONOPS and presenting the Operational 
View-One (OV-1) for the proposed training system. It then presents multiple vignettes 
that explore common scenarios detailing how the WFTS will operate. These vignettes 
illustrate how webfires will enhance in-port, underway, unit, and multi-unit training 
during the basic, integrated, advanced, and sustainment phases of the OFRP. 

B. WFTS CONOPS 

As shown in Table 7, by using technology such as actual and simulated 
communication links, augmented reality, hi-fidelity simulators, and actual combat 
systems in each phase of the OFRP, the scenarios performed in-port and underway will 
enable improved single unit and multi-unit training. 


Table 7. Types and Phases of Webfires Training 


Types of Training 

OFRP PHASE 

Basic 

Integrated 

Sustainment 

Unit 

In-Port 

X 

X 

X 

Underway 

X 

X 

X 

Multi-Unit 

In-Port 

N/A 

X 

X 

Underway 

N/A 

X 

X 


Looking at Figure 16, we see that as units conduct training and data is collected it 
can be used to aid organizations in evaluating and certifying units for the next phase of 
the OFRP. Additionally, that data is useful for evaluating the effectiveness of training, 
doctrine, and procedures that are developed for near-peer threats. 
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If training, procedural, or doctrinal gaps are discovered, they can be corrected and 
delivered to the fleet in a timely manner. Additionally, this figure shows that SMEs 
associated with near-peer threat doctrine and procedures can help create and manage the 
scenarios that are used to train the fleet. 
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Artificial Intelligence 
live Virtual Constructive Training 
Simulation 


High Velocity Learning 


Images from Navy.mil, GlobalSecurity.org, USFFC, NAVAIR, NAVSEA, SPAWAR, 
NWDC, ONI, CAE, IBM, and SECNAV. 


Figure 16. WETS CONOPS Diagram 


C. VIGNETTES 

A vignette is a brief description that is used to describe how a system will operate 
once it has been fully implemented. These descriptions are useful in the engineering 
process because they can aid engineers in placing system functions, requirements, and 
capability gaps in context. Using vignettes engineers can creatively analyze the capability 
gaps and explore ways that a system might close those gaps. 

This portion of the report uses illustrative descriptions to show how the future 
WETS can provide both unit and multi-unit training while CSG units are in-port or 
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underway during the basic, integrated, and sustainment phases of the OFRP. Although 
these vignettes are useful in identifying future capabilities, they may not be representative 
of the final capabilities that the future system will have. 

1. In-Port Unit Training 

A ship has just completed the maintenance phase of the OFRP and needs to 
prepare its crew to deploy with a CSG. Proficiency and currency are low and the crew 
needs to gain experience rapidly in order to move forward to integrated training with the 
CSG. 

While in port, the ship’s crew takes turns running simple preprogrammed 
scenarios on their shipboard systems that were developed by SMEs knowledgeable about 
enemy tactics and procedures. The goal of this training is to help familiarize watch 
standers with their consoles and equipment, and reinforce current doctrine, procedure, 
and tactics to which they should have been trained. Data is collected that allows the 
commanding officer and higher organizations to evaluate the crew’s performance and to 
determine the effectiveness of the training. This allows organizations to track whether a 
ship or unit needs special training to aid in preparing for the next phase of the OFRP. 
This data could also be used to certify a unit is ready to proceed to the integrated phase of 
the OFRP. During this phase of training, if a ship is unable to conduct onboard training 
due to maintenance actions it will be able to send watch standers to a shore facility where 
the same scenarios can be run on simulated shipboard equipment. 

2. Underway Unit Training 

While preprogrammed scenarios are useful in helping to train units, actual 
training at sea can greatly increase the training value by interjecting real world events, 
such as weather and connectivity issues, in communication systems. Adding the extra 
dimension of realism allows watch standers to receive more realistic training and better 
prepare them for a near-peer threat. Simulation adds value in training but reliance on too 
much simulation in the future can also be a disadvantage. 
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During this type of training, a ship can run preprogrammed scenarios that 
simulate real contacts through augmented reality. For instance, a ship can practice 
maneuvering to track and then attack a simulated submerged threat. As previously 
mentioned, data will be recorded to allow the ship and other organizations to evaluate 
performance and help certify the unit is ready to proceed to the integrated phase of the 
OFRP. Additionally, more advanced simulations can be produced to simulate friendly 
ships and aircraft to aid individual units in aspects of training that will be required for the 
integrated and sustainment phases of the OFRP. 

3. Multi-Unit Training During the Integrated Phase 

While in port, any combination of multiple ships, aircraft simulators, and ship 
simulators can connect to a network that will allow them to simulate the real world 
communications necessary to employ webfires as well as allow them to simulate a shared 
scenario. This simulation can be a preprogrammed scenario during the beginning of the 
integration phase, or it can consist of highly choreographed scenarios managed by a 
training organization during later phases of the integration and sustainment phases. 

All of the friendly units are played by the actual units that will be deploying 
together as a CSG or ESG. The location of each of those units is simulated as underway 
in the area in which they will be deploying. Expected opposition forces are developed, 
simulated, and controlled by SMEs at the relevant tactical training groups to provide 
high-fidelity enemy actions and responses during the more advanced stages of the 
integrated phase. Despite the geographical separation between the participants, some out 
to sea, some in port, and some unable to use their own ship’s systems due to equipment 
casualties, the entire strike group is able to integrate into a common operating picture to 
conduct integrated training. 

Eike single-unit training, data from multi-unit training can be recorded and used 
by organizations to help evaluate and certify units to continue into the next phase of the 
OERP or for deployment. Additionally, during these advanced threat scenarios, data can 
be recorded to evaluate the effectiveness of current doctrine, procedure, and tactics 
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employed by the fleet. If discrepancies are found, or more efficient means of prosecuting 
a target are discovered, the TTPs can be updated accordingly. 

4. Underway Sustainment Phase Training 

During this type of training, each unit can carry equipment (permanently installed 
or temporary) that will allow the unit to form and utilize a webfires network. For this 
exercise, each unit has put its system in training mode, allowing the unit to send and 
receive simulated combat data, shared by a common network seen by all. The servers 
needed to run the simulation software will be primarily housed on the aircraft carrier at 
the heart of the strike group. Other surface units have server racks that can help process 
and relay webfires data on a smaller scale in the carrier’s absence. 

With the simulation processing capability resident to the strike group, no 
connection back to the training centers on land is needed. SMEs embedded in the strike 
group in the form of Weapons and Tactics Instructors control the opposition forces and 
provide a sense of realism to enemy actions. Only the enemies and the weapons are 
simulated. For example, real fighters fly against computer-simulated aircraft, and ships 
execute real maneuvers against simulated submarine threats. Real communications and 
real console operations take place in training mode. For most console operators, there 
should be no appreciable difference between the simulated combat scenario on their 
consoles and what would appear on the consoles during actual combat. 
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VII. SYSTEM REQUIREMENTS 


After determining the capability gaps and the concept of operations of the new 
system, the next step in the systems engineering process is to identify the requirements 
that the system must fulfill in order to bridge those gaps while meeting the goals of the 
CONOPS. Requirements form the basis of the future system design. All functions and 
operational activities that a system possesses must fulfill all the stated requirements. 
Those functions and operational activities can then be used to assign tasks to operational 
nodes and components to meet system functions. For the purpose of this report, there are 
two basic types of requirements: capability requirements and functional requirements. 
These are described in detail in the following sections. 

A. CAPABILITY REQUIREMENTS 

A capability requirement (also known as an operational requirement) is a 
requirement delineating a capability that a system must have in order to meet the 
missions of a system (Defense Acquisition University 2017). Capability requirements 
directly relate to the CONOPS and how the future system will be employed to provide 
training and address the capability gaps identified in Chapter V. 

These capability requirements are a driving factor in the system architecture for 
the WFTS because capabilities are addressed by tasks that the system must accomplish. 
These tasks are then implemented by system functions, which are performed by system 
components. 

If capability requirements are not fully developed, it is possible that a system is 
built that does not adequately perform the missions of that system. Using capability gaps 
and the CONOPS developed earlier, the following capability requirements were 
developed. Each requirement is described in detail as this section maps the capability 
requirements to the capability gap(s) that it addresses. 
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1. Training Requirements 

These are requirements that directly focus on training the warfighter. These 
requirements focus on when, where, and how a warfighter and unit can train. 

a. The System Shall Integrate Webfires Concept Training during the 
Basic, Integrated, and Sustainment Phases of the OFRP 

By integrating the WFTS into the basic, integrated, and sustainment phases of the 
OFRP, units can train on webfires concepts throughout their entire training cycle prior to 
deployment and maintain their proficiency to use webfires after deployment. By 
introducing elements of webfires training into the OFRP cycle during the basic phase, 
units will progress though the integrated phase with greater proficiency and will then be 
more capable to fight a near-peer threat while on deployment or during the remainder of 
the sustainment phase. This will introduce integrated training in the basic phase through 
simulation. 

b. The System Shall Integrate Webfires Concept Training during Unit and 
Multi-Unit Training 

The nature of the webfires concept is to integrate units together to process a 
target. The integration of this training during unit and multi-unit training exercises will 
better prepare units to work together to defeat a near-peer threat. Integrating webfires 
concept training into unit training exercises will allow individual units to focus on 
specific training deficiencies that need improvement prior to conducting multi-unit 
training. 


c. The System Shall Integrate Webfires Concept Training In-port and Out- 
to-Sea 

By integrating webfires training with units in port and at sea, units will better be 
able to practice the skills necessary to perform webfires, regardless of location or 
underway schedules. 
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2. Repetition Requirements 

These requirements focus on increasing the number of repetitions that warfighters 
can do with respect to training. Repetitive high quality training will help increase 
retention of skills and knowledge. 

a. The System Shall Provide Standardized Training Scenarios for Unit and 
Multi-Unit Training 

Standardized scenarios enable units to have a set of standards by which they can 
be trained to fight a near-peer threat. This will also allow units to train to quality 
scenarios that are provided by SMEs on the enemy and the tactics that they employ. By 
using these standardized scenarios, units will not have to create their own and will be able 
to perform quality training with greater frequency. 

b. The System Shall Provide Training with Limited Communications 

By providing training in limited communications environments or in port, units 
will not have to rely heavily on real communications circuits or outside entities to provide 
communications. Thus, units will be able to perform more training. 

c. The System Shall Be Capable of Allowing Units/Simulators to 
Independently Establish Training Simulations with Other Units 

By allowing units or simulators to run simulations or scenarios with other units, 
multiple units can train independently from one another during all phases of the OFRP. 
This will allow units to practice integrated operations earlier in work-ups and prior to 
deployment, and will increase the quality of the training. Additionally, this means that 
units will not have to rely on some other entity to establish a training scenario for them 
and will allow multiple units to perform multiple multi-unit scenarios at the same time. 

d. The System Shall Integrate with and Be Capable of Integrating with 
Current and Future Strike Group Units, Networks, and Training 
Facilities/Simulators 

This will allow units to conduct training using their own systems instead of 
relying on simulators that may not be the actual equipment that sailors will use in combat. 
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Furthermore, this capability should allow simulator facilities to link up and conduct 
exercises with actual units. This will increase the quality of the training and allow for 
training to be done more frequently in port and at sea. 

3. Feedback Requirements 

These requirements focus on feedback that can aid high-velocity learning. 
Repetition is useful; however, if warfighters are not training correctly or more effectively 
then the value of that repeated training is less productive. 

a. The System Shall Provide Data that Can Be Used to Assess Effectiveness 
of Training, Doctrine, and Procedures against a Near-Peer Threat 

By providing this data, warfare experts can evaluate the effectiveness of the 
training and determine whether units need more attention to better prepare them for 
deployment. Additionally, this data is useful for informing the developers of tactics, 
doctrine, and procedures about the effectiveness of these elements against a simulated 
near-peer threat, allowing the TTPs to be updated as necessary. 

b. The System Shall Provide Data that Can Be Used to Evaluate and 
Certify Units during the OFRP Cycle 

The system can provide data that is useful to certify units, and this can reduce the 
time and separate certification requirements that units must meet in order to advance to 
the next phase of training. 

4. Summarized Capability Gaps 

For the reader’s benefit in correlating the requirements and gaps, the following 
list summarizes the capabilities gaps that where identified in Chapter V. 

1. Lack of Webfires Concept Training 

2. Lack of Multi-Unit Training Repetition to Support Additional Webfires 
Training Requirements 

a. Lack of Standardized Multi-Unit Scenarios for Training 
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b. Lack of Communications Bandwidth between Ships and 
Simulators 

c. Lack of Resources at TACTRAGRUPAC/LANT to Support 
Multiple Training Simulations Simultaneously 

3. Lack of Compatible Networks to Perform Multi-Unit Training 

a. Lack of Common lA Certifications to Integrate Data 

b. Lack of Ability to Interface Units and Facilities/Simulators 

4. Lack of a Quality Feedback Process 

a. Lack of Face-to-Face Debriefing by SMEs and Groups Conducting 
Multi-Unit Training 

b. Lack of Necessary Capability to Assess Webfires Training, 
Doctrine, and Procedures against a Near-Peer Threat 

c. Lack of Automated Data Processing for Expedited Evaluation of 
Training 

The mapping (traceability) of each capability requirement to a corresponding gap 
is shown in Table 8. By mapping the capability requirements to the capability gaps, the 
systems engineer introduces traceability and can ensure that the new system is addressing 
the identified capability gaps. Eailure to ensure that each capability gap identified is being 
addressed would result in a system that fails to meet the needs of the stakeholders. 

The WETS as envisioned in this report is unable to address capability gaps 3a and 
4a at this time. After thorough discussion, the team determined that these specific gaps 
are outside the scope of this report and will be recommended as future research topics. 


69 



Table 8. Mapping Capability Requirements to Capability Gaps 


Capability 

Gap 

Capability 

Requirement 

Discussion 

1 

la-lc 

A system designed to integrate webfires into unit and 
multi-unit training while at sea or in port during the 
basic, integrated, and sustainment training phases of the 
OFRP will address the gap of no current webfires 
concept training currently exists. 

2a 

2a 

Preprogrammed scenarios will address the gap of no 
preprogrammed scenarios. 

2b 

2b 

The ability to train with limited communications will 
address the lack of communications bandwidth between 
ships and simulators. 

2c 

2c 

The capability of units/simulators to establish their own 
scenarios will address the gap of having to rely on the 
limited resources of TACTRAGRUPAC/LANT. 

3a 

N/A 

The WFTS will not address this capability gap. 

3b 

3 

The WFTS’ capability to integrate with all units/ 
simulators will address the gap of lacking the ability to 
interface units and simulators. 

4a 

N/A 

The WFTS will not address this capability gap. 

4b 

4a 

Data provided by the new training system will fill gap of 
the current training system in providing the capability to 
assess training, doctrine, tactics, and procedures. 

4c 

4b 

Data provided by the new system will allow for faster 
evaluation and certification of training. 


B. FUNCTIONAL REQUIREMENTS 

“A functional requirement is simply a task (sometimes called an action or 
activity) that must be accomplished to provide an operational capability (or satisfy an 
operational requirement)” (AcqNotes 2017c). These functional requirements used to 
determine the functions that the components (hardware and software) of the system must 
perform in order to satisfy the capability requirements and close the gaps that were 
identified. 

Functional requirements are derived from capability requirements and are used to 
help develop system functions. Later in the systems engineering process, these functions 
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help to identify design alternatives and conduct an analysis of alternatives. The functional 
requirements identified for the WFTS include: 

1. The system shall be able to integrate with all CSG/ESG units’ weapons 
systems capable of conducting webfires. 

2. The system shall be able to interface with current and future webfires 
capable training facilities and simulators. 

3. The system shall be able to receive updates from the intelligence 
community of current enemy’s threats. 

4. The system shall be compatible with existing networks and ship systems. 

5. The system shall be able to provide standardized preprogramed 
simulations to the warfighters. 

6. The system shall provide the ability for units to modify preprogrammed 
simulations. 

7. The system shall provide the ability for units to create simulations. 

8. The system shall provide the ability for multiple units and training 

facilities to conduct the same integrated training scenarios simultaneously. 

9. The system shall support multiple simulations running concurrently. 

10. The system shall support the simulations being controlled by units, 
simulators, or commanders. 

11. The system will support the storage of simulations in a simulation bank. 

12. The system shall collect and provide data that can be used to evaluate the 

performance of the training system. 

13. The system shall collect and provide data that can be used to certify and 
evaluate units. 

14. The system shall use communication circuits available in 2025-2030. 

C. REQUIREMENTS SUMMARY 

This chapter discussed the capability requirements and functional requirements 
that the webfires concept must possess in order to fill the capability gaps. The capability 
requirements were then used to determine functional requirements that will help the 
system meet the capability requirements. Both the functional requirements and capability 
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requirements will be used to determine the operational activities (people/organizational 
functions) that the system must have and the system functions (hardware/software) that 
the system must possess to fulfill these capability requirements and functional 
requirements. These operational activities and system functions also help identify 
possible design alternatives that are discussed later in more detail in Chapter IX. 
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VIII. FUNCTIONAL ANALYSIS 


A. FUNCTIONAL ANALYSIS 

Functional analysis is a critical step in the systems engineering proeess. This 
analysis is performed in the eoneeptual design phase of any projeet that seeks to translate 
top-level system requirements into meaningful design criteria (Blanehard and Fabrycky 
2011, 86): “A funetion refers to a speeific or diserete action (or series of notions) that is 
neeessary to aehieve a given objeetive [and] may ultimately be aoeomplished through the 
use of equipment, software, people, faeilities, data, or various oombinations thereof’ (86). 

[FJunotional analysis is an iterative proeess of translating system 
requirements into detailed design criteria and the subsequent identifieation 
of the resourees required for system operation and support. It ineludes 
breaking requirements at the system level down to the subsystem, and as 
far down the hierarehioal struoture as necessary to identify input design 
criteria and/or eonstraints for the various elements of the system. The 
purpose is to develop the top-level system arehitecture, which deals with 
both “requirements” and “strueture.” (Blanehard and Fabrycky 2011, 86) 

Using tools such as functional decompositions and functional flow block 
diagrams, engineers ean determine the funetions that a system must have in order to meet 
system requirements. This ensures that all requirements are being met by the system; it is 
imperative that engineers verify that system requirements are traeeable to eaeh of the 
established system funetions. 

B. SYSTEM FUNCTIONS 

Within the arehiteeture for the WFTS, the team determined that there were 
numerous funetions that must be aceomplished in order to meet the requirements laid out 
in Chapter VII. These primary functions are depieted in Figure 17. 
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Figure 17. WFTS Primary Functions 


Furthermore, within each primary function, various sub-functions are needed to 
achieve the overall goal of the WFTS. To facilitate the hierarchy between these sub¬ 
functions, a functional decomposition structure is created for each primary function. 

1. Provide Simulation 

Within the Provide Simulation function of the WFTS, the first level hierarchy is 
shown in Figure 18. 



Figure 18. Provide Simulation Functional Hierarchy 


a. Receive and Store Simulations 

As a basis for training, especially with consideration to high-velocity learning, the 
WFTS must be able to receive and store simulations as published by the designated 
training leader during all stages of the OFRP. At the heart of multi-domain training is a 
common goal to be achieved for a given state. Based on what training simulation would 

be needed or expected to prepare warfighters for their deployment to various AORs, 

74 




































simulations would be given to all partieipating units from the theater commander. 
Correspondingly, each unit would need to store and readily obtain a training scenario 
from a WFTS simulation database. 

b. Create and Modify Simulations 

The WFTS must be able to quickly adapt to changing tactics, differing missions, 
geopolitical limitations, regulatory changes, etc. With such a plethora of variables that 
could potentially impact any number of missions, the training scenarios must be 
tailorable to mimic conditions that are to be expected throughout the world in varying 
theaters. Commanders will need to be able to either create a simulation from scratch, or 
be able to change any variables (referred to as “technical injects”) prior to enacting a 
simulation. Potential changes to force levels, maneuverability restrictions, battle damage, 
participating units, etc., will affect the fidelity of the training. Additionally, intelligence 
updates must be programmable into the simulations. 

c. Receive Intel Updates 

Actively inviting intelligence agencies’ inputs regarding potential enemy tactics 
and weapons would enhance the fidelity of scenarios—especially the simulation of these 
near-peer red forces in a cross-domain campaign simulation. Intelligence update data 
must be programmed into the system as expeditiously as possible. 

2. Communicate 

At the most basic level, the communication structure of the WFTS must maintain 
the ability for data and voice communications to reach the warfighters reliably and 
effectively. This must occur prior, during, and after any simulation or scenario is run on 
the variety of platforms with which the system will interact. These networks must be able 
to operate completely independently no matter where the units or simulators are 
physically located (i.e., in port or underway). A hierarchy of this function is shown in 
Figure 19. 
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Figure 19. Communicate Functional 

a. Transmit Data/Voice/Simulations 

In the 2025-2030 timeframe for which the WFTS is designed, networks are 
assumed to be established for cross-domain communications. These various wired and 
wireless networks shall provide the means to transmit data (for both the simulations 
themselves and the information gathered after running them) and voice signals before, 
during, and after scenarios. 

3. Conduct Simulation 

Each time the WFTS runs a simulation or scenario, it must be controlled by either 
human operators or artificial intelligence algorithms. This control will not only be within 
the organization that has cognizant control over the conduct of all the players, but also 
within the equipment and simulators that are used. The functional hierarchy for this is 
shown in Figure 20. 
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Figure 20. Conduct Simulation Functional Hierarchy 
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a. Control Simulations 

At any time, a participant unit in a scenario will perform tasks based on 
parameters such as previous training, human factors, and available information. The 
scenario lead must establish the beginning, end, and desired pauses while the scenario is 
running. Therefore, the system must allow the assigned lead to maintain control. In 
addition, simulation modifications, such as technical injects, may occur after a scenario 
has been initiated. The lead must be able to control what information changes in real time 
to allow for more realistic and effective training. 

b. Stimulate Sensors Onboard Units and Simulators 

With the linking of units to simulators during a WFTS scenario, maximum 
fidelity and learning will occur if the warfighter is able to see what he or she would see in 
an actual event. Therefore, it is paramount to ensure that equipment, both within the 
simulator tool and aboard actual ships, reacts properly: giving actual displays that 
correspond to what should be expected in a combat environment. 

4. Interface with Network 

The network that provides the backbone for the WFTS’ operation must 
accomplish two main interface functions—^interaction with the human end-users of the 
system and interaction of system components in an information technology infrastructure. 
Figure 21 depicts this hierarchy, which is expanded in the following discussion. 
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Figure 21. Interface with Network Functional Hierarchy 
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a. Interface with Human 

The WFTS will utilize the latest technology for relaying information as quickly as 
possible. This information will include such data as the effect of the unit’s actions, 
probability of kill, and other vital tactical information. The graphical display will be 
designed to mimic what information would be provided during an actual engagement. 
Additionally, displays for the scenario lead or training commander will allow for 
immediate feedback regarding individual unit effectiveness and level of preparedness for 
each unit’s corresponding OFRP phase. These functions are shown in Figure 22. 
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Figure 22. Interface with Human Functional Hierarchy 


As a complement to activation of shipboard equipment during a unit-to-unit or 
simulator-to-unit scenario, WFTS will interact with warfighters via sensors or indications 
on equipment that they are familiar with, to enhance tactical effectiveness. 

b. Interface with System 

WFTS has an extensive relationship between the various systems aboard a unit 
and at simulation facilities. This is where the major benefits of the systems can truly be 
realized to accomplish commander’s intent. The interactions include links from: 

• Unit-to-unit: i.e., watch standers on surface ships, airborne units, and a 
submarine bridge-team 

• Unit-to-simulator: i.e., USMC pilots in shore-based simulator, and 
submarine bridge-team 
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• Simulator-to-simulator: i.e., Surface Officer Warfare School simulator and 
P-3 simulator 

Information will travel via the aforementioned communication networks to 
achieve these connections. These functions are depicted in Figure 23. 



Figure 23. Interface with System Secondary Functional Hierarchy 


(1) Provide Multi-Unit Network 

The network simulations will be run by units or in simulators. The latter 
representing a shore-based, established training facility. The units can either be 
networked in port, via shore command, control, and communication (C3) facilities, or by 
at sea C3 networks. 

(2) Provide Standalone Network 

Due to the limited bandwidth potential or threat of operating in a denied/degraded 
environment, WFTS simulations must be able to operate via standalone systems. Each 
unit will need the ability to execute required training without dependence on traditional 
at-sea or in-port connections. Infrastructure will include digital media able to record 
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results during standalone simulations, as well as an ability to upload feedback data once a 
network is available. 

5. Store Feedback Data 

In addition to providing information instantaneously to participants, the feedback 
must be stored for playback and analysis during the debrief. This can aid in improving 
future training (i.e., best/worst practices) and individual unit performance metrics. In this 
manner, decision making among WFTS participants during a simulation can contribute to 
future modifications of TTPs for use in a webfires construct. A breakdown of functions is 
shown in Figure 24. 
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Figure 24. Store Feedback Data Functional Hierarchy 


C. OPERATIONAL ACTIVITIES 

After defining and decomposing the functions of an optimally designed WFTS, it 
is then important to understand how the new system will accomplish the unique 
operational requirements of stakeholders. By taking a higher, overarching view of the 
system and then further breaking down activities that will be performed, the systems 
engineer can identify the roles that can be assigned to units and supervised by cognizant 
commands. 

Described in detail later in this report, the primary way to demonstrate operational 
activity relationships in DOD programs is to utilize DoDAF diagrams. One of these 
diagrams, the Operational Activity Decomposition Tree (OV-5a) will show the iterative 


80 









nature of operational activities that accomplish the functions listed previously in this 
chapter. Based on the OV-5a, Figure 25 depicts the relationship between the WFTS and 
the activities that need to be performed by the system. 



Figure 25. Overall WFTS Operational Activities 


1. Support Training 

To support training on a webfires network, additional operational activities will be 
accomplished as shown in Figure 26. 



Figure 26. Support Training Operational Activity Hierarchy 
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a. Collect Intelligence on Enemy 

Within the purview of a webfires network, warfighters must know what to expect 
from adversary units. The intelligence inputs to the WFTS allow for a simulated near¬ 
peer threat to display real-time tactics and capabilities for more realistic learning and 
contributing to a high-velocity learning concept. 

b. Establish Training Objectives 

In order to evaluate the training process (described later in this chapter), the 
objectives of the fleet-wide usage of the WFTS must be established and changed as 
necessary to match the commander’s intent. This occurs at the fleet (geographic) and type 
(platform) command levels. 

c. Establish Scenarios 

At multiple command levels and during each phase of the OFRP, scenarios will 
be established to match what their respective units will expect to encounter in an AOR. 
This occurs at the fleet (geographic), CSG/ESG (strike group), unit (individual vessel), 
and multi-unit (interoperation between vessels exclusive of the strike group), and cross¬ 
domain (interoperation encompassing all potential fleet and platform) levels. 

d. Create Doctrine/Tactics/Procedures 

Based on feedback garnered from WFTS events, modifications will be 

implemented to simulation protocols based upon warfighter actions and enemy tactics for 
optimization of offensive and defensive actions in an operational webfires environment. 

2. Conduct Training 

In order to conduct training to implement a webfires network, additional 
operational activities will be accomplished as shown in Figure 27. 
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Figure 27. Conduct Training Operational Activity Hierarchy 

a. Facilitate/Create/Modify/Receive Scenarios 

After scenarios have been designed and implemented, the responsibility to 
facilitate and dictate actions within a scenario will exist. This occurs at much the same 
command levels as seen in the creation activities. Scenarios will be manipulated, 
transmitted, and received to match the conditions within which the cognizant commands’ 
respective units can be expected to act. This activity occurs at the fleet, CSG/ESG, unit, 
multi-unit, and cross-domain levels. 

b. In-port/At-sea/Hybrid Training 

At the heart of cross-domain training exists the capability to link all individual 

units and simulators, independent of geographic location or seaworthiness, and conduct 
training events. 

c. Produce Feedback 

The training events will be recorded and analyzed by commands to optimize the 
scenarios and drive necessary changes in TTPs. 

3. Evaluate Training 

In order to evaluate the effectiveness of the WFTS, additional operational 
activities will be accomplished as shown in Figure 28. 


83 




































































Figure 28. Evaluate Training Operational Activity Hierarchy 


a. Evaluate and Certify Fleet/Strike Groups/Units 

Prior to and when established in the deployment and advanced phase of the 
OFRP, commands must be able to meet their numbered-fleet commander’s intent. The 
WETS will establish the opportunity for shore-based leaders and fleet commanders to 
evaluate feedback data from training scenarios. 

b. Evaluate Doctrine/Tactics/Procedures 

As the database of feedback grows, intelligence and tactical development 
organizations will evaluate warfighter actions within training scenarios to determine 
whether a more effective action would produce more favorable offensive or defensive 
outcomes for a given set of conditions. 

c. Evaluate Type Training 

Operational and tactical leaders will have the ability to evaluate the overall 
effectiveness of the training provided to various types of vessels. 
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IX. ANALYSIS OF ALTERNATIVES 


This chapter corresponds to the final major phase of the project. These are the 
steps where a specific solution begins to emerge. Analysis of alternatives is a process in 
which multiple design options, or solutions, are developed and compared against one 
another to determine the best solution. The team started this process using a creativity 
tool called a morphological box to help develop alternative solutions. Next, the team 
developed the criteria against which the design alternatives would be compared to 
determine the best solutions. 

These design criteria came from the Critical Operating Issues (COI), and the 
Measures of Effectiveness (MOE) used to measure how well a design meets the 
requirements. Once the alternatives and grading criteria were developed, the next step 
was to evaluate how well each alternative meets the specified criteria and assign values 
for comparison. Eor this project, the team determined that not all of the criteria should be 
equally weighted. Swing weights were used to determine which MOEs should be 
considered of higher importance than others. The assigned values were multiplied by 
their associated swing weights to determine an overall measure of effectiveness (OMOE) 
for each design alternative. 

A. MORPHOLOGICAL BOX 

The design of any system requires choosing the right components to provide the 
required functionality. The use of a morphological box overcomes the limitations of 
normal quantitative methods of analysis. Normal quantitative methods, including 
modeling and simulation, fail to capture the non-quantifiable attributes of the factors 
involved (Richey 2017). The morphological box approach captures the complexity of a 
design without the need for a rigorous mathematical approach. 

The morphological box approach helps us choose design alternatives that meet 
our high-level functions. Underneath each high-level function is a list of component 
alternatives that are composed of similar components designed to meet the higher level 
function. Design alternatives are built by selecting a number of component alternatives 
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from each high-level function category. All of the selected components comprise the 
design alternative. Each design alternative must have, at a minimum, one component to 
satisfy each of the higher level functions. 

Our design alternatives represent the basic level componentry required to build 
the system. Each of the design alternatives was chosen using a training vignette described 
further in this chapter. The alternative component list was chosen for each function based 
on our best estimate of 2030 technology levels and feasibility based on recent military 
technology history. 

To provide simulations, we chose three alternatives. 

• Artificial Intelligence would provide the simulation a reactive response to 
user inputs based on concepts derived from machine learning. The AI 
would study the current battlefield simulation and make intelligent enemy 
decisions in order to provide the best simulated response. Ideally, this 
machine learning would be programmed to react according to tactics 
typically employed by a specified enemy. 

• Manual control of the simulation would place SMEs in control of the 
opposition forces. Enemy decisions made in the simulation would need 
manual input from the SMEs for the simulation to carry out. 

• Pre-Programmed is a form of simulation in which a SME would write 
the simulation events and timing of those events from an enemy 
perspective. The SMEs would provide this simulation script for units to 
have available and utilize at a later time. Enemy actions would be fixed 
and predictable after multiple simulation runs. 

Communication between the different training nodes was determined by looking 
at four different communication methods. 

• Hardwire communications would include fiber optics, DSE, and T- 
carriers. These components would physically link shore-based facilities 
with either additional facilities or pier-side ships. The components are not 
prone to interference and have a relatively low cost. Hardwire has the 
greatest bandwidth but is limited to stationary connections. 

• Over the Horizon (OTH) communications would include high frequency 
radio communications. The ability to greatly extend the network out to sea 
is extremely beneficial. Using the properties of the atmosphere, the signal 
can bounce between the surface and the ionosphere to well beyond the 
range of traditional line-of-sight communications. The bandwidth is 
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somewhat limited and the hazard of transmitting near personnel is 
significant. 

• Line-of-Sight (LOS) communications could include ultra-high frequency 
(UHF), very-high frequency (VHF), satellite communications, Link 16, 
Link 11, and Link 4. The properties of these communications allow for 
higher bandwidths at reduced ranges. Ranges can be extended with 
repeaters placed either along the surface or at higher altitudes. The 
limitation is that both the transmitting/receiving antennas must physically 
see each other. The waveform does not allow for atmospheric bouncing 
and is more susceptible to degradation from weather phenomena. 

• Satellite Communications technically use LOS frequencies, but for 
purposes of this project have been distinguished from other non-satellite 
LOS communication methods. Satellite LOS communications allow for 
much greater separation of units as curvature of the Earth is much less of a 
factor than it is for LOS communications that do not utilize satellite relays. 

Providing the simulation to the user could be accomplished using three different 
methods. 

• Non-Console hardware could include laptops, handheld computers, or 
other electronics. The hardware is not designed to represent the consoles 
or equipment found in the CSG, but represent one or more features that 
would be found within a CSG. For example, a laptop could run a program 
designed to simulate the radar console found on a destroyer. The single 
user interface would provide additional time to learn simple tasks to 
operate the webfires hardware. 

• Simulated Console hardware could include aviation simulators, ship 
combat system simulators, and submarine combat system simulators. The 
hardware would best represent the actual hardware used in the CSG/ESG 
with inputs modeled by computer simulations. 

• Actual Console hardware includes what the user would actually use in the 
CSG/ESG environment. Actual equipment provides the greatest level of 
training fidelity and provides the user the greatest learning environment. 

Controlling and evaluating the simulation could be accomplished using three 
methods. 

• Central Control concept involves a training headquarters that provides 
both the training scenario and tools to evaluate the simulation in real time. 
Eor example. Navy Training Groups are shore-based facilities that 
broadcast a computer simulation to actual units located in exercise areas. 
These simulations provide the data for actual units to run exercises 
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without the need for actual red forces. The simulation is monitored for 
performance at the shore-based facility. 

• Local Control concept involves a smaller SME team than a central 
control facility would have available to it. The vision is that a local control 
center could be located on the flagship within the CSG/ESG for exercises 
out to sea, or could be a shore facility located in the fleet concentration 
areas to handle controlling and evaluating the training event. The SME 
team at the local control center will provide all control, including event 
sequence and reaction to user decisions. This is intended to be similar to 
central control, but on a smaller scale, while adding the capability to 
establish a local control center for strike groups that are far out to sea. 

• Unit Control concept involves non-SME members running training 
events at the unit level. Eor example, if two helicopters wished to conduct 
unit-level training at sea they could control their own training event. Eor a 
surface ship, this control method would be very similar to using the Battle 
Eorce Tactical Trainer (BETT) to perform training exercises. Eor this 
project, unit control does not mean that one of those units must be in 
control of the simulation, but rather it means that units have the capability 
to control the simulation if so desired. Units capable of controlling 
simulations at the unit level could still take part in training exercises where 
control over the simulation rests with a central station. 

How the data is shared between the nodes of the network can be modeled using 
three network topologies. 

• Single Star Networks rely on a single node to transmit and receive data 
between the other training nodes. An example of this network topology 
would be training group centers. The data is sent out and received by one 
node and rebroadcasted to the CSG/ESG. 

• Multiple Star Networks are similar to single star networks but include 
links that group single star networks into multiple star networks. The 
additional capability provides at-sea and shore units to operate on the 
same network. 

• Mesh Networks would allow any unit to directly communicate with any 
other unit in the network. With the mesh network, each unit has its own 
capability to communicate with other units in the WETS. 

Storing the training and feedback data is possible using three methods. 

• Centralized data storage would occur at off-site data storage locations. 
Similar to cloud storage, the data is accessible anywhere on the network 
and managed by third-party support. 


88 



• Unit data storage could include a server located on each unit within the 
CSG/ESG that captures the data from the exercises in which that unit 
participates. This data could then be uploaded to a centralized network 
without the need for physical transportation of portable media devices. 

• Portable Media could include CDs, external HDDs, or USB memory. 
This would be applicable to unit-level training where network connectivity 
may not be feasible. 

The alternative methods to accomplish the major architecture functions were 
placed into the morphological box as shown in Table 9. 


Table 9. Morphological Box 
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The team has chosen all of the design alternatives for evaluation from this 
morphological box. Design alternatives are chosen by selecting one or more of the 
options under each of the six major system functions. 

B. DESIGN AUTERNATIVES 

From the morphological box, the team chose several design alternatives intended 
to showcase various aspects of the WFTS. Ultimately, the team chose to study a total of 
nine different design alternatives. Fach of these design alternatives has been numbered in 
order of assessed training value, where option one had the highest overall training value 
and option nine had the lowest overall training value. 

1. Fully capable system addresses all major capability gaps identified. 

2. Strike group out to sea integrated with a shore-based simulator network. 
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3. 


A ship out to sea integrated with a ship in port. 

4. A squadron of similar units integrating for training out to sea. 

5. Ships in port integrating with a shore based simulator. 

6. A strike group conducting sustainment training at sea. 

7. Fleet synthetic training exercise integrating in port or at sea units during 
the integrated phase. 

8. Low-fidelity trainer integrating units at sea and in port. 

9. Single unit in port being fed a scenario from a local training center. 

Each of these options is discussed in greater detail in the following sections. 

1. Design Alternative One 

Design Alternative One (DAI) was designed to be the most capable WETS, 
integrating both in-port and at-sea operational units with simulators to perform training in 
all three phases of the OERP. This option was designed to be capable of performing the 
training scenarios of all of the other design alternatives combined. A decision maker 
would choose this option when an unlimited budget is available. Eigure 29 represents the 
networking and interfacing capabilities expected from DAI. 
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Images from businessinsider.com, wikipedia.org, huntingtoningalls.com, nationstates.net, 
suwalls.com, sandiegouniontribune.com, ndtv.com, and boeing.com. 

Figure 29. Design Alternative One Network Interfaee Diagram 


The morphologieal box for DAI is shown in Table 10. The eells highlighted in 
red and bolded are the options seleeted for DAI. 


Table 10. Design Alternative One Funetions 
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The AI option provides high fidelity simulations that ean be repeated frequently 


during the basie and sustainment phases. The manual simulations, great for the integrated 
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training phase, allow for the highest fidelity training exercises at the hands of SMEs, but 
with fewer repetitions due to the resources involved in such simulations. The 
combination of using both AI and manually controlled simulations can provide very high 
fidelity simulations that can be conducted with optimal repetition. By including the 
option for all four communications methods, we can use each method where appropriate 
to allow for full integration of both in-port and at-sea units with shore-based simulators. 

Units would be conducting webfires training using actual combat systems, while 
simulated combat systems (high fidelity simulators) would be used to conduct webfires 
training at shore-based facilities. When each unit has the capability to control the 
simulation, the units do not have to rely upon the availability of a central or local control 
station to conduct training exercises. Combined with the mesh network architecture, 
where any unit or simulator can establish a connection with any other unit or simulator, 
any two units available for training can link up and conduct training simulations together. 
For DAI, the option was chosen to store feedback data on a centralized server. This 
allows faster and greater access to training data across the fleet as each unit can review or 
study exercises from other units. Units can also download or stream simulations from the 
standardized, central database. 

2. Design Alternative Two 

DA2 was chosen to meet the requirements for conducting strike group training 
exercises out to sea by integrating with simulators in port. An example of when this 
alternative might be desirable is during the beginning of the integrated phase, when the 
strike group ships go out to sea, but the units of the air wing will participate in the 
exercise from a shore training facility. When the strike group is fully integrated, such as 
during the later stages of the integration phase or even the sustainment phase, the 
simulator facilities on shore might consist purely of opposition forces. Figure 30 
represents the networking and interfacing capabilities expected from DA2. 
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Images from businessinsider.com, wikipedia.org, huntingtoningalls.com, nationstates.net, 
suwalls.com, ndtv.com, and boeing.com. 

Figure 30. Design Alternative Two Network Interface Diagram 


The morphological box for DA2 is shown in Table 11. The cells highlighted in 
red and bolded are the options selected for DA2. 


Table 11. Design Alternative Two Functions 
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As in DAI, the combination of manual and pre-programmed simulations allows 
for high fidelity and high repetition. By using preprogrammed enemy actions during 
simulations instead of enemy actions simulated with AI, we anticipate a reduced 
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effectiveness. However, with the option to communicate via hardwire, LOS, and satellite 
communications, the major communication methods for transferring high data volumes 
either in port or at sea are maintained. This system maintains full integration capability 
between units and simulators. 

The use of actual and simulated combat systems maintains a high degree of 
fidelity. DA2 utilizes a central control of the simulation, relying on a shore-based central 
control facility to push the simulation to the strike group via satellite data networks. The 
multiple star network option allows for multiple shore-based simulators to form the first 
star network with the central control station, which can then transfer the simulation data 
to the strike group flagship. The flagship would then act as the hub for a second star 
network made up of the strike group units at sea. Data could be recorded and stored at a 
centralized facility on shore. 

3. Design Alternative Three 

DAS focuses on the elements needed to integrate units at sea to conduct simulated 
training exercises with units in port. This design alternative came about because it is not 
always possible to get all of the desired participants either at sea together or in port 
together on a regular basis. Sometimes equipment casualties and the need for other 
training events often dictate in port and at sea schedules. That concern goes away with 
this alternative as it allows for integration between at-sea and in-port units. Figure 31 
represents the networking and interfacing capabilities expected from DAS. 
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Images from businessinsider.com, wikipedia.org, huntingtoningalls.com, 
nationstates.net, suwalls.com, sandiegouniontribune.com, ndtv.com, and 
boeing.com. 


Figure 31. Design Alternative Three Network Interface Diagram 


The morphological box for DAS is shown in Table 12. The cells highlighted in 
red and bolded are the options selected for DAS. 


Table 12. Design Alternative Three Functions 
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The combination of manual and preprogrammed simulations allows for high 
fidelity and frequent repetition. A shore-based central control station would provide the 
hub of a star network. Hardwire communications can be used to link units in port to the 
hub, while units at sea would be connected to the hub via satellite communication links. 
In the event an in-port unit’s combat system is down, that unit can relocate its watch 
teams to a nearby simulator facility located at its fleet concentration area. 

4. Design Alternative Four 

DA4 is designed to allow at sea training of a squadron of units such as a Surface 
Action Group or an air wing, but not a complete strike group. The intention of this design 
alternative is to implement webfires training into type group (TYCOM) training exercises 
that take place before integrating with the rest of the strike group. Figure 32 represents 
the networking and interfacing capabilities expected from DA4. It is not necessarily 
limited to the destroyer squadron SAG portrayed in the figure. The type group could be 
made up of a submarine squadron, an air wing, or any other webfires-capable squadron. 



Images from huntingtoningalls.com. 


Figure 32. Design Alternative Four Network Interface Diagram 


The morphological box for DA4 is shown in Table 13. The cells highlighted in 
red and bolded are the options selected for DA4. 
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Table 13. Design Alternative Four Functions 
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The combination of manual and preprogrammed simulations allows for high 
fidelity and optimal repetition. The difference for this alternative is that the manual 
control would most likely be carried out by one of the units designated as the unit 
controlling the simulation. LOS and satellite communications provides ample data rates 
between units integrated at sea. Any decrease in fidelity from not having the SMEs 
associated with a central control station controlling opposition forces will be offset by the 
increase in fidelity from the simulations taking place on the actual webfires combat 
systems via combat system simulators. Without a connection to a central or local hub to 
control the simulation, units participating in this type of at-sea training must have the 
capability for unit control. Units would be directly integrated with each other using a 
mesh network, with a unit designated as the control unit for that simulation. 

5. Design Alternative Five 

DAS allows multiple ships in port to integrate with a shore-based simulator 
facility. This is similar to the current FST system, but with the notable addition of also 
running preprogrammed scenarios. This design alternative could be used for an entire 
strike group in port participating with a shore-based simulation facility, or this design 
alternative could be used for only one ship in port participating with a shore-based 
simulation facility. Figure 33 represents the networking and interfacing capabilities 
expected from DAS. 
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Images from sandiegouniontribune.com, ndtv.com, and boeing.com. 

Figure 33. Design Alternative Five Network Interface Diagram 


The morphological box for DAS is shown in Table 14. The cells highlighted in 
red and bolded are the options selected for DAS. 


Table 14. Design Alternative Five Functions 
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The combination of manual and preprogrammed simulations allows for high 
fidelity and optimal repetition. Since all units are stationary, either on land or in port, 
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hardwire will provide a cost-effective solution for communications at high data rates. 
Simulated combat system consoles and actual combat systems consoles were selected to 
represent the actual combat systems on the ship as well as the simulator facility on shore. 
The redundant communications paths of a mesh network are not necessary for this 
hardwired training network, so a single star network should suffice. Units can store their 
own data for later evaluation. 

6. Design Alternative Six 

The vision for DA6 was a strike group conducting sustainment training at sea, far 
from shore-based simulator facilities. The idea here is the strike group might be making a 
long ocean transit as part of a deployment or might just be out to sea together for 
sustainment training as a strike group after returning from a deployment. One goal for 
this design alternative was minimal reliance upon shore facilities while conducting 
training. Training associated with DA6 is expected to be the closest design alternative to 
actual webfires employment. Figure 34 represents the networking and interfacing 
capabilities expected from DA6. 
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Images from businessinsider.com, wikipedia.org, huntingtoningalls.com, nationstates.net, 
and suwalls.com. 


Figure 34. Design Alternative Six Network Interface Diagram 
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The morphological box for DA6 is shown in Table 15. The cells highlighted in 
red and bolded are the options selected for DA6. 


Table 15. Design Alternative Six Functions 
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The combination of manual and preprogrammed simulations allows for high 
fidelity and frequent repetition. Here the SMEs controlling the exercise would be located 
on the flagship of the strike group. These could be a few civilian contractors whose 
expertise is in the enemy’s tactics, or they might be members of the U.S. Navy’s 
intelligence community, or Weapons and Tactics Instructors who might have expertise 
comparable to the SMEs found at shore training facilities, such as the tactical training 
groups, but are still recognized as experts in their warfare areas. Because this training 
scenario is isolated to the strike group out to sea, EOS was chosen exclusively. 

Satellite communications might not be available in the environment where the 
strike group is expected to be employing webfires, and so this WETS design does not use 
satellites to communicate. Actual combat consoles were chosen because each unit in the 
strike group will be conducting the training simulation using their actual combat units. 
The difference would be that the consoles would be in a training mode that allows them 
to display simulated sensor data. Simulation would come from a local control center 
residing within the strike group, likely the CVN or the EHD/EHA. Units would interface 
using a WETS mesh network, which is the network architecture that the webfires system 
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would be expected to employ. Each unit in the strike group would store its own 
performance data locally. 

7. Design Alternative Seven 

DA7 aims to represent a blend of the current FST architecture and the Composite 
Training Unit Exercise (COMPTUEX) architecture. The major difference between this 
design alternative and FST or COMPTUEX, is that this design allows for the in-port units 
to participate alongside at-sea units. Figure 35 represents the networking and interfacing 
capabilities expected from DA7. 



Images from businessinsider.com, wikipedia.org, huntingtoningalls.com, nationstates.net, 
suwalls.com, sandiegouniontribune.com, and boeing.com. 

Figure 35. Design Alternative Seven Network Interface Diagram 


The morphological box for DA7 is shown in Table 16. The cells highlighted in 
red and bolded are the options selected for DA7. 
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Table 16. Design Alternative Seven Functions 
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MULTIPLE 

STAR 

UNIT 

PRE¬ 

PROGRAMMED 

LOS 

ACTUAL 

CONSOLE 

UNIT CONTROL 

MESH 

PORTABLE 

MEDIA 


SAT COMMS 






For this design alternative all simulations are provided with manual control of the 
opposition forces by trained SMEs located at one of the tactical training groups. Units at 
sea would communicate simulation data using LOS communications, while units in port 
would use hardwire communications. To network the in-port units with the units at sea, 
satellite communications would be used. This communication would occur using a single 
star network with a central control station hub to push the simulations out to the 
participants’ actual combat systems or simulator combat system consoles located at 
shore-based facilities. The central control station would store the data for performance 
evaluation. 


8. Design Alternative Eight 

DAS represents units in port and at sea participating in a low fidelity trainer 
scenario. This type of training might be valuable at the end of the basic phase in 
preparation for entering the integrated phase, or it might be useful in the sustainment 
phase to maintain proficiency. Figure 36 represents the networking and interfacing 
capabilities expected from DAS. 
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Images from huntingtoningalls.com and sandiegouniontribune.com. 

Figure 36. Design Alternative Eight Network Interface Diagram 


The morphological box for DAS is shown in Table 17. The cells highlighted in 
red and bolded are the options selected for DAS. 


Table 17. Design Alternative Eight Eunctions 


Functions 

Provide 

Simulation 

Communicate 

Stimulate 

Sensors/Units 

Control 

Simulation 

Interface 

With 

Network 

Store Feedback 
Data 

ARTIFICIAL 

INTEL 

HARDWIRE 

NON¬ 

CONSOLE 

CENTRAL 

CONTROL 

SINGLE 

STAR 

CENTRALIZED 

MANUAL 

OTH 

SIMULATED 

CONSOLE 

LOCAL CONTROL 

MULTIPLE 

STAR 

UNIT 

PRE¬ 

PROGRAMMED 

LOS 

ACTUAL 

CONSOLE 

UNIT CONTROL 

MESH 

PORTABLE 

MEDIA 


SAT COMMS 






This alternative uses simple preprogrammed simulations designed to maintain 
proficiency in entry level tactics and decisions. Preprogrammed simulations were chosen 
for their ease of uploading and repetition. A non-console system was chosen to represent 
a low fidelity trainer such as a laptop, where a warfighter can log in when time is 
available and interface with another participant. Hardwire communications would be 
used for units on land, while satellite communications would be used to interface with 
units at sea. At each end, units would likely network into local hubs that would then 
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communicate with each other, but control of the simulations would reside with one of the 
participating units. 

9. Design Alternative Nine 

DA9 represents a single unit in port reeeiving a preprogrammed scenario from a 
local shore-based simulation facility. This type of scenario can be used during any of the 
phases, depending on the preprogrammed simulation provided. During the integrated 
phase, integration can be simulated by preprogramming virtual participants into the 
simulation. Figure 37 represents the networking and interfacing capabilities expected 
from DA9. 



Images from sandiegouniontribune.com and boeing.com. 

Figure 37. Design Alternative Nine Network Interface Diagram 


The morphological box for DA9 is shown in Table 18. The cells highlighted in 
red and bolded are the options selected for DA9. 


Table 18. Design Alternative Nine Functions 


Functions 

Provide 

Simulation 

Communicate 

Stimulate 

Sensors/Units 

Control 

Simulation 

Interface 

With 

Network 

Store Feedback 
Data 

ARTIFICIAL 

INTEL 

HARDWIRE 

NON¬ 

CONSOLE 

CENTRAL 

CONTROL 

SINGLE 

STAR 

CENTRALIZED 

MANUAL 

OTH 

SIMULATED 

CONSOLE 

LOCAL 

CONTROL 

MULTIPLE 

STAR 

UNIT 

PRE¬ 

PROGRAMMED 

LOS 

ACTUAL 

CONSOLE 

UNIT CONTROL 

MESH 

PORTABLE 

MEDIA 


SAT COMMS 
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Preprogrammed simulation allows for frequent repetition as the seenario ean be 
run multiple times aeeording to the unit’s own sehedule. As the unit is in port, hardwire 
provides a eost-effeetive means of eommunieation baek to a simulator faeility. The unit 
performs the exereises using its own aetual eombat systems to maintain fidelity. A loeal 
eontrol faeility would transmit the simulation to the unit via a star network. This allows 
multiple units to utilize the same loeal eontrol eenter to simultaneously eonduet different 
training seenarios. Units would store their own performanee data to have on hand for 
evaluation upon eompletion of the training. 

C. TRADE-OFF BETWEEN COMPONENTS 

The team identified six high-level system funetions of the WFTS. These six high- 
level system funetions are: provide simulation, eommunieate, stimulate units, eontrol 
simulation, interfaee with network, and store data. Based on these system funetions, the 
team identified three to four methods to fulfill eaeh funetion. After identifying the list of 
methods, the team eondueted a trade-off analysis of the eomponents to determine the 
advantages and disadvantages of eaeh method. 

1. Providing Simulation 

Artifieial intelligenee has the potential to rnimie enemy’s taeties while not relying 
on the SMEs to manually run the seenarios. When the AI is programmed with input from 
the SME, the major benefit is that that units ean now run higher fidelity preprogrammed 
seenarios that do not rely on the availability or logistieal burdens that must be eonsidered 
when running high fidelity seenarios through a eentral training faeility, as is the ease 
during COMPTUEX. AI seenarios provide frequent repetition training opportunities 
while maintaining the high fidelity enemy aetions seen with SME eontrolled systems. 
The problem with AI systems is the high eost and time eommitment neeessary for the AI 
programming. 

Manually eontrolled simulations rely heavily on the knowledge of SMEs to 

ensure the fidelity of enemy taeties employed and their responses to friendly aetions. At 

the hands of SMEs, manually eontrolled simulation provides the highest fidelity enemy 

taeties that warfighters ean train against. The trade-off for the high fidelity aehieved in 
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manual simulations, though, is the limited number of repetitions in conducting exercises. 
The resource requirements to ensure SMEs are available for every training exercise of 
every unit would be prohibitive. 

Preprogrammed simulations are low cost and easily repeatable so that warfighters 
can make evaluations and adjustments to improve performance with each iteration. 
However, the trade off with preprogrammed simulations is that they typically have low 
tactical fidelity and events become predictable after several iterations. 

2. Communicate 

Hardwire communications such as fiber optics or Local Area Network (LAN) 
lines provide the highest data rates and are inexpensive to implement over short 
distances. However, the drawback to the great data rates hardwire can provide is limited 
by mobility. Hardwire communications do not lend themselves to effective use between 
ships at sea. 

Over-the-Horizon communications provide at-sea communication capabilities 
using High Lrequency (HL) waves that can bounce off the atmosphere to travel great 
distances. However, data rates associated with HL communications are expected to be too 
low to transmit the amount of data needed for webfires training scenarios. Additionally, 
HL communications can pose a radiation hazard for personnel near the antennas, such as 
may be the case with multiple ships in port. 

Line-of-sight communications offer high data rates for units that are in direct sight 
of one another. The downside of LOS communications is that the curvature of the Earth 
limits the ranges in which LOS communications can be used without the need for relays 
or very high antennas. 

Satellite communications are technically LOS communications using satellites as 
relays. These communications offer similar data rates to other LOS communications, but 
allow for communicating that data over much greater ranges. The trade-off is that the 
need for satellites makes this option very expensive and these satellites are not always 
available for training due to competing priorities. 
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3. 


Stimulate Units 


Actual combat systems provide the highest fidelity but are the most expensive to 
build and maintain. Actual combat systems typically come with higher manpower 
demands as each relevant console needs an operator to perform that console’s functions. 
Additionally, performing training on actual combat systems might not be possible if those 
systems are down for maintenance. 

Simulated combat systems provide medium fidelity and, depending on the 
location, can be utilized by multiple units. Simulated combat systems can be used as a 
backup when actual combat systems are unavailable, but typically they do not offer the 
same fidelity. 

Non-combat system consoles such as a laptop or a stand-alone system are the 
cheapest and offer the greatest potential for repetition. Simulations on non-combat 
systems are assessed to have the lowest fidelity of training. 

4. Control Simulation 

Both central control and local control are great for unity of command, but each 
can become a single point of failure because of its lack of redundancy. By contrast, unit 
control does not rely on a central or local control node; every Webfires capable unit can 
control the simulation. 

5. Interface with Network 

Both the star network and multiple star networks are the most common topology. 
A central hub controls and monitors all connected units. It is relatively easy for the units 
to connect and disconnect from the network. The disadvantage of this type of network is 
its reliance on the central hub. When the central hub fails, it brings down the entire 
network. By contrast, a mesh network is much more robust and reliable. When one of the 
nodes goes down, it does not bring down the entire network. 
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6 . 


Store Data 


Centralized storage contains all available data and allows easy access for all units. 
However, due to its lack of redundancy it can become a single point of failure. Local 
storage provides the unit with easy access to its own data without relying on the network. 
While a portable medium is very convenient and low cost, it takes a long time to transfer 
data to its destination. The other disadvantage of both local storage and portable media is 
that they only contain partial picture data. 

The results of the components trade-off analysis are summarized in Appendix C. 

D. COST EFFECTIVE TRADE-OFF 

As stated in Chapter II, cost effectiveness is addressed from a qualitative rather 
than quantitative analysis here. The cost-effective trade-offs will now be discussed in 
greater detail. After an analysis of the previously described components, we find the 
more capable systems tend to have higher costs associated with them. This is expected; as 
capabilities increase, expected costs often increase, too. Nevertheless, there are ways to 
reduce costs throughout the process without loss of capability. 

The major capability gaps identified were a lack of repetition and a lack of 
integration. Increasing repetition by conducting training at sea more often would lead to 
cost increases. Training simulations, by comparison, can be conducted more cheaply and 
quickly than getting underway or conducting flight operations. Imagine a unit is going to 
conduct five training exercises at sea. Using training simulations, the unit might replace 
two of those at-sea exercises with four to six in-port training exercises in the same time. 
Costs would be reduced by not burning the fuel or paying for port operations to get 
underway and return. Additionally, the unit will have now completed seven to nine 
training exercises, three at sea and four to six simulated, in the same time it had originally 
planned to conduct only five exercises. Simulation allows greater frequency of training at 
reduced costs by reducing the underway time needed for training. 

By utilizing lower fidelity preprogrammed simulations, the costs of simulation 

could be even further reduced in comparison with the more expensive simulations such as 

those using AI or SMEs in manual control. Using non-combat system consoles could 
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further reduce the cost to provide training simulations, but again, at the expense of 
fidelity. The major trade-offs seem to be between repetition, fidelity, and costs. A 
reasonable trade-off seems to be to focus on low cost, low fidelity, and highly repetitive 
simulations earlier in the OFRP. As training progresses, low cost simulations could give 
way to more expensive, higher fidelity, less repeatable simulations, and live exercises. 

Increasing the training simulation capacity and integration capability will be a 
large capital expense. Nevertheless, there is potential for great cost efficiency if the same 
training proficiency can be obtained while decreasing underway time or flight hours. If 
unit or mission loss can be prevented through more effective warfighting, the cost 
efficiency is even greater. 

E. CRITICAL OPERATING ISSUES AND MEASURES OF 

EFFECTIVENESS 

From the morphological box provided earlier in this chapter, the team chose 
methods to accomplish each function and to evaluate how well those options meet 
training objectives. As a first step, the specific evaluation criteria must be developed. The 
team developed these criteria by reviewing the capability and functional requirements 
and by developing a list of Critical Operating Issues (COI). Each COI was then broken 
into several Measures of Effectiveness (MOE). 

1. COI I - How well does the system support training during the OERP 
cycle? 

MOE 1.1: System fit into the Basic Phase 
MOE 1.2: System fit into the Integrated Phase 
MOE 1.3: System fit into the Sustainment Phase 

2. COI 2 - How well does the system train to a near-peer threat? 

MOE 2.1: Scenario management 
MOE 2.2: Understanding enemy 
MOE 2.3: Identify warfighter decisions 

3. COI 3 - How well does the system provide relevant data to support 
evaluation? 
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MOE 3.1: Automation of data processing 

4. COI4 - How well does the system integrate units and simulators? 

MOE 4.1: Integration within units or simulators 
MOE 4.2: Integration between units and simulators 
MOE 4.3: Integration at sea 
MOE 4.4: Integration at sea with in-port units 
MOE 4.5: Integration in port 

5. COI 5 - How well does system implement the principles of high-velocity 
learning? 

MOE 5.1: Eidelity 

MOE 5.2: Repetition 

MOE 5.3: Retention 

Descriptions of each COI and MOE are provided in the following paragraphs. 

1. COI 1 - How Well Does the System Support Training during the 
OFRP Cycle? 

Eor this project, it was important to the team that the webfires training 
architecture fits into the existing greater navy training architecture, such as the OERP, 
where feasible. Training takes place during the OERP primarily in three phases: the basic, 
integrated, and sustainment phases. It was desirable that the proposed webfires training 
system also fit into these three phases for ease of transition and implementation. 

a. MOE 1.1: System Fit into the Basic Phase 

This MOE is designed to evaluate how well the proposed webfires training 
architecture meets the unit-level training expectations laid out in the Basic Phase, 
including both the at-sea and in-port portions. 

b. MOE 1.2: System Fit into the Integrated Phase 

This MOE is designed to evaluate how well the proposed webfires training 
architecture meets the training expectations laid out in the Integrated Phase, including 
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both the at-sea and in-port portions. This MOE is also intended to capture how well the 
system can perform unit training requirements that are periodically recurring from the 
basic phase. 

c. MOE 1.3: System Fit into the Sustainment Phase 

This MOE is designed to evaluate how well the proposed webfires training 
architecture meets the training expectations laid out in the Sustainment Phase, to 
including both the at-sea and in-port portions. This MOE is also intended to capture how 
well the system can perform both unit and multi-unit training requirements that are 
periodically recurring from the basic and integrated phases. 

2. COI2 - How Well Does the System Support Training to a Near-Peer 
Threat? 

This COI is designed to assess how well the system supports training to a high 
level, complex threat scenario. The ultimate purpose of the training architecture is to train 
warfighters in the doctrines and tactics used to counter an enemy threat. 

a. MOE 2.1: Scenario Management 

This MOE is designed to encompass an array of performance measures that could 
be used to determine how difficult a scenario is to manage. These factors would include 
the difficulty in creating and modifying a scenario, the difficulty in scheduling a scenario, 
and the difficulty in bringing participants together to take part in a designated scenario. 

b. MOE 2.2: Understanding Enemy 

This MOE is designed to capture how well the warfighter can understand a given 
enemy’s intentions and predict the near-future actions of that enemy. Understanding an 
enemy’s likely course of action is important to countering that enemy. One goal of this 
training architecture is to ensure the enemy portrayed in simulations is represented as 
accurately as possible. 
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c. MOE 2.3: Identify Warfighter Decisions 

This MOE is designed to capture the actions and decisions of the warfighter and 
analyze the impact of those decisions on the simulation. The intent is to identify the 
decisions made and, through an analysis and feedback process, determine whether the 
decisions made were the correct decisions in accordance with doctrine and training, 
tactics, and procedures. 

3. COI3 - How Well Does the System Provide Relevant Data to Support 
Evaluation and Feedback? 

An important aspect of effective training is an iterative process involving training, 
evaluation, and feedback. After engaging with stakeholders and from the team’s own 
fleet experience, it was determined that delays in the evaluation process cause delays in 
future training opportunities. Additionally, it was determined that evaluation and 
feedback are most effective when they are provided in a timely manner upon completion 
of the training simulation. 

a. MOE 3.1: Automation of Data Processing 

This MOE is designed to capture the automation in processing that data that may 
be used to evaluate a unit or warfighter’s performance during a scenario. Stakeholder 
interviews cited a several hour delay in the evaluation and feedback process when 
simulation tapes need to be reviewed prior to providing performance feedback. If the 
system could be programmed to automate the evaluation process, it is possible to evaluate 
at near real time. Additionally, performance feedback data could be provided at near real 
time. Reducing the delay in receiving feedback could reduce the delay before 
commencing the next iteration of training. 

4. COI 4 - How Well Does the System Integrate Units and Simulators? 

Integration is one of the largest gaps the team identified through stakeholder 
interactions. Air, surface, and subsurface communities all have simulators to train their 
respective communities, but those simulators rarely have the capability to integrate with 
other simulators of the same community, let alone the simulators of other communities. 
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The team determined if integration is the ultimate goal of a strike group employing 
webfires, then integration between the communities must take place as early and often as 
is feasible. Integrating simulators and units across all communities should help achieve 
these integration goals. 

a. MOE 4.1: Integration within Units or Simulators 

This MOE measures the effectiveness of the proposed system to integrate units of 
a strike group with other units, or to integrate simulators with other simulators. It is not 
intended to measure a simulator’s ability to integrate with a unit. 

b. MOE 4.2: Integration between Units and Simulators 

This MOE is designed to measure the effectiveness of a unit to integrate with a 
simulator. All units composing a strike group are to be considered, as are all simulators 
used across the communities. 

c. MOE 4.3: Integration at Sea 

This MOE measures how well units integrate with each other at sea for training 
simulations. This considers units at sea in coastal regions where they may be stimulated 
from shore facility antennas as well as units far out to sea, such as crossing an ocean on 
the way to or from deployment. 

d. MOE 4.4: Integration at Sea with In-Port Units 

This MOE captures how well strike group units out to sea can integrate with units 
that remain in port. It is not always feasible to have all units designated to participate in a 
particular training exercise together in port or together out to sea. If the system can 
integrate units at sea with units in port, this would alleviate that constraint. 

e. MOE 4.5: Integration in Port 

This MOE measures the effectiveness of the strike group to conduct integrated 
training scenarios in port, similar to the EST events conducted today. 
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5. COI5 - How Well Does the System Implement the Principles of High- 
Velocity Learning? 

The weapon systems wielded on the battlefield today are more complex than ever 
before and so is the training associated with employing those weapon systems. It is of 
vital importance to train better and more quickly to stay ahead of a potential adversary. 
This COI addresses how well the proposed training system achieves the principles of 
high-velocity learning. 

a. MOE 5.1: Fidelity 

This MOE captures the fidelity of the training taking place. It is intended to 
capture all aspects of fidelity, including the fidelity of the weapons and tactics employed, 
the fidelity of enemy responses to warfighter actions, and the fidelity of the console or 
simulator used to provide the training. 

b. MOE 5.2: Repetition 

This MOE captures the ease of repetition of a proposed training architecture. 
During stakeholder engagement and from personal experience, the team identified a lack 
of repetition when it comes to training, particularly integrated training at the strike group 
level. The Repetition MOE will capture how easy it is for a particular training simulation 
to be repeated multiple times based on the anticipated time commitment, number of 
players involved, access to the required hardware or software, and depending on how the 
training simulation is controlled. 

c. MOE 5.3: Retention 

This MOE measures how well a warfighter or unit is expected to retain the 
information and experience learned during training simulations. Retention is thought to 
be a function of the number of times a training is conducted and the level of fidelity for 
that training. While this is a qualitative assessment, it is thought that repetition will have 
a larger impact than fidelity with regard to retention. 
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F. OVERALL MEASURE OF EFFECTIVENESS 

The Overall Measure of Effectiveness (OMOE) is a means of assessing the 
performance of alternative systems in an analysis of alternatives. The OMOE process 
starts with engineers determining the MOEs by a system can be evaluated, then they 
determine the Measures of Performance (MOP) for each MOE, and then the key 
performance parameters that are used to measure those MOPs (Parnell, Driscoll and 
Henderson 2010). 

The following discussion and approach to swing weights follows the process as 
laid out in Parnell, Driscoll, and Henderson’s, Decision Making in Systems Engineering 
and Management. While all MOEs and MOPs are important, some are more important to 
mission accomplishment than others and should be weighted more significantly. In order 
to account for this, the team used a swing weight matrix to rank the importance of MOEs 
in relation to each other. Once the ranking relationship of the MOEs is determined a 
normalized weighted value on a scale of zero to one can be determined to account for 
these MOEs’ importance (Parnell, Driscoll and Henderson 2010). 

Since the WETS is a broad architectural concept being evaluated as a qualitative 
assessment, specific performance numbers associated with evaluating MOPs would 
convey little value. Therefore, the team makes a qualitative assessment of how well each 
alternative is expected to perform the MOEs. The qualitative assessment will be 
normalized as a value ranging from zero to one. 

Once the normalized swing weights and normalized values for the MOEs have 
been determined, the OMOE value can be determined using Equation 1, where V(x) is the 
OMOE for design alternative jc, Wi is the normalized swing weight for a particular MOE, 
and v(jCi) is the MOE qualitative normalized value for design option x with respect to 
each particular MOE (Parnell, Driscoll and Henderson 2010, 295). 


It 

F(x) = ^ WiV(Xj) 

i=l 


{Eq. 1) 
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The sum product of these two values results in an OMOE value scaled between 
zero and one for each design alternative. These OMOE values may then be directly 
compared across the design alternatives to determine which design was assessed to have 
the highest performance. 

G. DETERMINATION OF SWING WEIGHTS 

In order to determine a normali z ed weight, the team had to qualitatively assess 
each MOE on two qualities. The first was how large a capability gap is the MOE 
assessing, and the second is how important is the MOE to the mission. The capability gap 
assessment was then broken into three sub-categories: low, medium, and high. The level 
of importance was also broken into three categories: mission critical, mission effective, 
and mission enhancing. This breakdown is shown in Table 19. 


Table 19. Swing Weight Identification Matrix 




Level of Importance 



Mission 

Mission 

Mission 



Critical 

Effective 

Enhancing 

Capability 

Gap 

High 

A 

C 

E 

Medium 

B 

E 

H 

Low 

D 

G 

I 


Derived from Parnell, Driscoll and Henderson 2010, 299. 


The lettering system in Table 19 indicates the cells labeled with lower alphabetic 
letters are more important than the other cells that have higher alphabetic letters. In other 
words, A>B>C and so forth. If multiple MOEs are put into a given cell, then the MOE at 
the top of the cell is weighted as more important than or equal to the ones listed below it. 

Once all the MOEs have been assigned a proper location in the table, and using 
the alphabetic ranking system, we can assign each MOE a non-normalized value. Once 
each MOE has a value, those values can then be normalized to a value between zero and 
one using Equation 2, where fi is the non-normalized swing weight for a particular MOE 
that the team assigned in Table 20 (Parnell, Driscoll, and Henderson 2010, 298). 
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{Eq. 2) 


Table 20 shows each MOE that the team identified and the non-normalized swing 
weight ranking of each MOE in reference to the Table 19. The normalized swing weight 
values for all the MOEs found using Equation 2 are presented in Table 21. 


Table 20. WETS Non-Normalized Swing Weight Matrix 




Eevel of Importance 



Mission Critical 

Mission Effectiveness 

Mission Enhancing 



MOE 

Score 

MOE 

Score 

MOE 

Score 



1.1 

99 

5.2 

79 

3.1 

45 



1.3 

98 

4.3 

78 



o 

Earge 

4.2 

73 







4.4 

70 



'Jq 

Medium 

5.3 

88 

2.2 

58 



cd 

u 

5.1 

84 

4.1 

56 



Small 

1.2 

65 

2.3 

38 

2.1 

19 





4.5 

31 




Table 21. WETS Normalized Swing Weight Matrix 



Eevel of Importance 

Mission Critical 

Mission Effectiveness 

Mission Enhancing 

MOE Score 

MOE Score 

MOE Score 

Capability Gap 

Earge 

1.1 0.101 

1.3 0.100 

5.2 0.081 

4.3 0.080 

4.2 0.074 

4.4 0.071 

3.1 0.046 

Medium 


2.2 0.059 

4.1 0.057 


Small 

1.2 0.066 

2.3 0.039 

4.5 0.032 

2.1 0.019 
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H. DETERMINATION OF QUALITATIVE VALUES FOR MOES 


Each MOE for each alternative is based upon a qualitative scale in order to 
determine the value of the MOE to be used in the OMOE process. Table 22 shows the 
qualitative scale that the team used. Table 23 shows the non-normalized MOE values, 
and Table 24 shows the normali z ed MOE values. 


Table 22. MOE Assessment Scale 


Assessment Scale 

Value 

Normalized Value 

Does not Meet MOE 

0 

0 

Partially Meets MOE 

1 

0.25 

Eully Meets MOE 

2 

0.5 

Moderately Exceeds MOE 

3 

0.75 

Greatly Exceeds MOE 

4 

1 


Table 23. Non-Normalized MOE Values 


Design Alternative 


MOE 

Weight 

1 

2 

3 

4 

5 

6 

7 

8 

9 

1.1 

Eits into basic phase 

0.101 

4 

2 

2 

2 

2 

0 

0 

4 

2 

1.2 

Eits into integrated phase 

0.066 

4 

3 

3 

3 

2 

2 

3 

0 

0 

1.3 

Eits into sustainment phase 

0.100 

4 

2 

2 

3 

2 

2 

0 

2 

2 

2.1 

Scenario management 

0.019 

1 

2 

3 

3 

2 

3 

1 

4 

4 

2.2 

Understanding enemy 

0.059 

4 

3 

3 

3 

3 

3 

2 

1 

1 

2.3 

Identify warfighter decisions 

0.039 

4 

3 

3 

3 

3 

3 

2 

1 

3 

3.1 

Automation of data processing 

0.046 

4 

3 

2 

3 

2 

2 

0 

2 

2 

4.1 

Integration within units or simulators 

0.057 

4 

4 

4 

4 

2 

4 

3 

0 

0 

4.2 

Integration between units and simulators 

0.074 

4 

4 

0 

0 

3 

0 

1 

0 

0 

4.3 

Integration at sea 

0.080 

4 

4 

4 

4 

0 

4 

2 

0 

0 

4.4 

Integration at sea with in port unit 

0.071 

4 

0 

4 

0 

0 

0 

2 

0 

0 

4.5 

Integration in port 

0.032 

4 

0 

4 

0 

4 

0 

3 

0 

0 

5.1 

Eidelity 

0.086 

4 

3 

3 

3 

3 

3 

3 

1 

2 

5.2 

Repetition 

0.081 

3 

3 

2 

3 

3 

3 

1 

4 

4 

5.3 

Retention 

0.090 

3 

3 

2 

3 

3 

3 

2 

3 

3 
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Table 24. Normalized MOE Values 


Design Alternative 


MOE 

Weight 

1 

2 

3 

4 

5 

6 

7 

8 

9 

1.1 

Fits into basic phase 

0.101 

1 

0.5 

0.5 

0.5 

0.5 

0 

0 

1 

0.5 

1.2 

Fits into integrated phase 

0.066 

1 

0.75 

0.75 

0.75 

0.5 

0.5 

0.75 

0 

0 

1.3 

Fits into sustainment phase 

0.100 

1 

0.5 

0.5 

0.75 

0.5 

0.5 

0 

0.5 

0.5 

2.1 

Scenario management 

0.019 

0.25 

0.5 

0.75 

0.75 

0.5 

0.75 

0.25 

1 

1 

2.2 

Understanding enemy 

0.059 

1 

0.75 

0.75 

0.75 

0.75 

0.75 

0.5 

0.25 

0.25 

2.3 

Identify warfighter decisions 

0.039 

1 

0.75 

0.75 

0.75 

0.75 

0.75 

0.5 

0.25 

0.75 

3.1 

Automation of data processing 

0.046 

1 

0.75 

0.5 

0.75 

0.5 

0.5 

0 

0.5 

0.5 

4.1 

Integration within units or 
simulators 

0.057 

1 

1 

1 

1 

0.5 

1 

0.75 

0 

0 

4.2 

Integration between units and 
simulators 

0.074 

1 

1 

0 

0 

0.75 

0 

0.25 

0 

0 

4.3 

Integration at sea 

0.080 

1 

1 

1 

1 

0 

1 

0.5 

0 

0 

4.4 

Integration at sea with in port 
unit 

0.071 

1 

0 

1 

0 

0 

0 

0.5 

0 

0 

4.5 

Integration in port 

0.032 

1 

0 

1 

0 

1 

0 

0.75 

0 

0 

5.1 

Fidelity 

0.086 

1 

0.75 

0.75 

0.75 

0.75 

0.75 

0.75 

0.25 

0.5 

5.2 

Repetition 

0.081 

0.75 

0.75 

0.5 

0.75 

0.75 

0.75 

0.25 

1 

1 

5.3 

Retention 

0.090 

1 

1 

1 

1 

1 

1 

1 

1 

1 


1. OMOE FOR ALL DESIGN ALTERNATIVES 

Now that the values of each MOE for each alternative and the normalized swing 
weights have been determined, the OMOE for all the design alternatives can be 
determined using Equation 1, where the OMOE is the sum product of the normali z ed 
weighted values and the normalized qualitative value of the MOE. Table 25 shows the 
results of the OMOE analysis. 


Table 25. OMOE Values for Each Design Alternative 


Design 

Alternative 

1 

2 

3 

4 

5 

6 

7 

8 

9 

OMOE 

Value 

0.9429 

0.6705 

0.6498 

0.6259 

0.5474 

0.5224 

0.3932 

0.3869 

0.3772 
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The design alternatives are listed again here for convenience. 

1. Fully capable system addresses all major capability gaps identified. 

2. Strike group out to sea integrated with a shore based simulator network. 

3. A ship out to sea integrated with a ship in port. 

4. A squadron of similar units integrating for training out to sea. 

5. Ships in port integrating with a shore based simulator. 

6. A strike group conducting sustainment training at sea. 

7. Fleet synthetic training exercise integrating in port or at sea units during 
the integrated phase. 

8. Low fidelity trainer integrating units at sea and in port. 

9. Single unit in port being fed a scenario from a local training center. 

Table 25 indicates that DAI had the highest training value as determined by its 
OMOE, while DA9 had the lowest training value. It should be expected that DAI has the 
highest value as this system was designed to allow for webfires training under all 
anticipated conditions and during all phases of the OFRP. 

The purpose in determining the OMOE for each design alternative is to determine 
which alternative had the best score and to allow for comparisons between alternatives. 
The real value of Table 25 is that it shows the relative scores of the different design 
alternatives and how they compare. Design alternatives two, three, and four were all very 
comparable in training value, while alternatives five and six were grouped close together, 
and finally seven, eight, and nine were grouped close together. 

Additionally, if a decision maker were to determine they do not need all of the 
capabilities provided in DAI, or the budget does not support DAI, that decision maker 
could look at the other alternatives and choose a lower cost option with less capability. 
The OMOE values provide an indication of the abstract potential value of the WETS that 
is gained or lost depending on the design alternative chosen. 

As a budget is not available for consideration, and the costs of these design 

alternatives are not being considered, the natural recommendation is to move forward 
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with DAI. It is important to note that the OMOEs calculated in Table 25 are the result of 
the weights and scores determined by the team after consultation with stakeholders. 
Individual stakeholders may regard each MOE with a different weight, or assess an 
alternative’s performance in that MOE differently. To explore the possible impact of 
changing the weights on the OMOE values, a sensitivity analysis was conducted. This 
process will be discussed in the following section. 

J. SENSITIVITY ANALYSIS PROCESS 

The identification of the swing weights above is subjective, therefore, the ranking 
of alternatives may be sensitive to variations in the weighted value resulting in one 
alternative’s OMOE being higher than another. It is important to perform sensitivity 
analysis to show the stakeholder that while a particular alternative may have a higher 
OMOE based on the current assessment scale, minor changes in preference could result 
in different alternatives having higher OMOE values. This can then be used to aid in 
determining the most appropriate design alternative and help inform decision makers 
about potential risk and uncertainty. 

In order to determine the sensitivity of a particular swing weight the following 
information needs to be determined, as shown in Table 26. 


Table 26. Information for Sensitivity Analysis 


Information 

Description 

Yi 

Current OMOE value for Alternative 

Y2 

Normalized MOE value for associated Swing Weight being assessed 

Xi 

Normalized Swing Weight value for MOE being assessed 

X2 

Value is 1 


Table 27 shows the calculations performed for DAI. This information will be 
used to aid the reader in understanding how sensitivity analysis was performed. The same 
calculations were repeated for each design alternative. 
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Table 27. Sensitivity Analysis Caleulations for DAI 


MOEs 

Normalized 

Swing 

Weight 

(Wi) 

Option 

MOE 

value 

(Vi) 

Produet 
(Wi X Vi) 

1.1 

Eits into Basie Phase 


1 

0.1009 

1.2 

Eits into Integrated 


1 

0.0663 

1.3 

Eits into Sustainment 


1 

0.0999 

2.1 

Seenario Management 

0.019 

0.25 

0.0048 

2.2 

Understanding Enemy 

0.059 

1 

0.0591 

2.3 

Identify warfighter deeisions 

0.039 

1 

0.0387 

3.1 

Automation of Data Proeessing 

0.046 

1 

0.0459 

4.1 

Integration within units or simulators 

0.057 

1 

0.0571 

4.2 

Integration between units and simulators 

0.074 

1 

0.0744 

4.3 

Integration at sea 

0.080 

1 

0.0795 

4.4 

Integration at sea with in port unit 

0.071 

1 

0.0714 

4.5 

Integration in Port 

0.032 

1 

0.0316 

5.1 

Eidelity 

0.086 

1 

0.0856 

5.2 

Repetition 

0.081 

0.75 

0.0604 

5.3 

Retention 

0.090 

0.75 

0.0673 


OMOE 

Option 

0.9429 


Using the sample data from Table 27, Table 28 will show the sensitivity data 
needed for sensitivity analysis. 


Table 28. Sample Data for Sensitivity Analysis of MOE 1.1 


Information 

Sample Data 

Yi 

.9429 

Y2 

1 

Xi 

0.101 

X2 

1 


Using the equation for the determination of the slope of a linear line and the 
equation for a linear line; the slope and y-intereept ean be determined and plotted on a 
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graph. This process is repeated for each design alternative and can then be plotted as 
shown in Figure 38. 

Once the equations for all the other design alternatives have been determined and 
plotted, the team can then see if these lines cross. The value for a particular swing weight 
that would result in an alternative being chosen over another alternative can be observed 
at the intersections of lines. That swing weight value can be calculated by taking the 
equation of two lines that cross, setting them equal to each other, and then solving for the 
swing weight value using algebra. 

The next section of this report will show the results of the team’s sensitivity 
analysis. Although all MOES were analyzed, only the relevant MOEs that are sensitive 
will be discussed below. 

K. SENSITIVITY ANALYSIS RESULTS 

Sensitivity analysis was conducted for the top four design alternatives, DAI 
through DA4, using spreadsheet software. There were a total of eight instances where 
changing the swing weights would change the order of the OMOEs, and only one of 
those instances where DAI was no longer the highest OMOE. Each of those instances 
will be discussed in more detail according to the affected MOE weights. 

I. MOE 1.3 Fits into Sustainment Phase 

Eor all MOE 1.3 weights, DAI remains the preferred design, but the order of 
some of the other designs change as the MOE weight changes. The current weight for 
MOE 1.3 is 0.102. DA3 is dominated by DA4 once the weight increases to 0.18, while 
DA2 is then dominated by DA4 for MOE 1.3 weights greater than 0.24. Eigure 38 shows 
the impact of MOE 1.3 weight on the first four design alternatives. 
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Figure 38. MOE 1.3 Sensitivity Analysis 

2. MOE 2.1 Scenario Management 

This is the only weight where DAI does not always dominate the other designs. 
The current weight for MOE 2.1 is 0.020. If this weight is increased beyond 0.38 DAI 
becomes dominated by DA3, with DA3 remaining the preferred design. Eigure 39 shows 
the impact of MOE 2.1 weight on the first four design alternatives. 



Eigure 39. MOE 2.1 Sensitivity Analysis 
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3. 


MOE 3.1 Automation of Data Processing 


For all MOE 3.1 weights, DAI remains the preferred design, but the order of 
some of the other designs change as the MOE weight changes. The current weight for 
MOE 3.1 is 0.036. DA3 is dominated by DA4 once the weight increases to 0.13. Eigure 
40 shows the impact of MOE 3.1 weight on the first four design alternatives. 



Eigure 40. MOE 3.1 Sensitivity Analysis 


4. MOE 4.2 Integration between Units and Simulators 

Eor all MOE 4.2 weights, DAI remains the preferred design, but the order of 
some of the other designs change as the MOE weight changes. The current weight for 
MOE 4.2 is 0.066. DA4 is dominated by DA2 once the weight increases to 0.03, while 
DA3 is then dominated by DA2 for MOE 4.2 weights greater than 0.05. Eigure 41 shows 
the impact of MOE 4.2 weight on the first four design alternatives. 
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Figure 41. MOE 4.2 Sensitivity Analysis 


5. MOE 4.4 Integration at sea with in Port Unit 

For all MOE 4.4 weights, DAI remains the preferred design, but the order of 
some of the other designs change as the MOE weight changes. The current weight for 
MOE 4.4 is 0.066. DA4 is dominated by DAS once the weight increases to 0.05, while 
DA2 is then dominated by DAS for MOE 4.4 weights greater than 0.09. Figure 42 shows 
the impact of MOE 4.4 weight on the first four design alternatives. 



Figure 42. MOE 4.4 Sensitivity Analysis 
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6 . 


MOE 4.5 Integration in Port 


For all MOE 4.5 weights, DAI remains the preferred design, but the order of 
some of the other designs change as the MOE weight changes. The current weight for 
MOE 4.5 is 0.043. DA4 is dominated by DAS once the weight increases to 0.008, while 
DA2 is then dominated by DAS for MOE 4.5 weights greater than 0.05. Eigure 43 shows 
the impact of MOE 4.5 weight on the first four design alternatives. 



Eigure 43. MOE 4.5 Sensitivity Analysis 


7. MOE 5.2 Repetition 

Eor all MOE 5.2 weights, DAI remains the preferred design, but the order of 
some of the other designs change as the MOE weight changes. The current weight for 
MOE 5.2 is 0.072. DAS is dominated by DA4 for all weights greater than 0.16. Eigure 44 
shows the impact of MOE 5.2 weight on the first four design alternatives. 
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Figure 44. MOE 5.2 Sensitivity Analysis 


8. MOE 5.3 Retention 

For all MOE 5.3 weights, DAI remains the preferred design, but the order of 
some of the other designs change as the MOE weight changes. The current weight for 
MOE 5.3 is 0.092. DA3 is dominated by DA4 for all weights greater than 0.17. Eigure 45 
shows the impact of MOE 5.3 weight on the first four design alternatives. 



Eigure 45. MOE 5.3 Sensitivity Analysis 
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X. SYSTEM ARCHITECTURE 


System architecture is a means of conveying the complexity of a system in ways 
that can show its properties, relationships, and behaviors from different viewpoints (DOD 
Deputy Chief Information Officer 2017a). The process is similar to traditional 
architecture, where an architect will create multiple blue prints or drawings to describe a 
structure. To further the example, one blueprint may be an illustration that shows the 
architecturally significant aspects of a structure to a customer financing a house, while 
another blueprint for the general contractor may be more detailed, showing the home’s 
electrical wiring plan. In both architecture and systems engineering, there is a need for 
multiple views that must be modeled from different perspectives in order to design and 
build a complex system. 

For the purpose of this report, the DOD Architectural Framework (DoDAF) will 
be used to depict these viewpoints. The DoDAF is the standard used by the DOD and will 
allow for common understanding. Some non-DoDAF tools have been incorporated in the 
following discussion to show views of the system that are important but have no 
corresponding standard DoDAF view. 

A. ARCHITECTURAL OVERVIEW 

The team completed the process of problem identification, stakeholder 
identification, gap analysis, and CONOPS generation that enabled the determination of 
capabilities requirements. The WFTS needs to fill the capability gaps that were 
determined through research and stakeholder engagement. The capabilities requirements 
allowed for the determination of operational activities (organizational functions) that 
must be performed by the nodes (organizations). After nodes (organizations) and 
operational activities where determined, the operational items (information passing 
between organizational functions) were determined. This then allowed for needlines 
(communication pathways between nodes) to be determined to support the exchange of 
operational items. After all of these were determined, the team could then identify the 
functions and functional requirements that components (hardware/software) would have 
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to meet in order to support the operational activities and meet the capabilities 
requirements of the system. Finally, using an analysis of alternatives approach, the team 
determined a final design of components that would best fulfill the capability 
requirements of the system. 

The organizations, components, requirements, and functions (people and system) 
and their inter-relationships that are necessary to fill the capability gaps are shown in 
Figure 46. They are discussed in greater detail throughout this chapter. 



Adapted from CORE Architecture Definition Guide (DoDAF v2.02). 
Figure 46. WFTS Architectural Overview 


B. ARCHITECTURAL VIEWPOINTS 

The success of any system depends on the foundation provided to design, 
implement, support, and potentially build upon, improve, or expand that system. This 
creates a synergistic relationship that converts raw material and data entering a well- 
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designed system into a viable end-product that meets or exceeds customer needs and 
requirements. The viewpoints that are used to show the relationships are described briefly 
in Table 26. 


Table 29. Architectural Viewpoints 


View Point 

Description 

Operational Resource Flow 
Description (OV-2) 

Shows the nodes (organizations) and the 
needlines (communication connections) 
between other nodes. 

Operational Items Transfer 
Matrix 

Shows the operational items 
(information) that is being passed along 
each needline that connects each node. 

State Transition Description 
(OV-6b) 

Shows the sequencing of the operational 
activities. 

Operational Activity Model 
(OV-5b) 

Shows the nodes, operational activities 
that they perform, and the operational 
items that are being passed between 
operational activities. 

Capability to Operation 

Activity Mapping (CV-6) 

Shows the capabilities that each 
operational activity is supporting. 

Operational Activity to 

Systems Function Traceability 
Matrix (SV-5a) 

Shows the functions of the system that 
implement/support the operational 
activities. 

Functions to Systems 
Traceability Matrix 

Shows what components comprise the 
system, what functions each component 
performs, and what operational activity it 
supports when combined with the SV-5a. 

Capability Requirements to 
Functional Requirements 
Traceability Matrix 

Shows the mapping between functional 
requirements and capability requirements. 

Functional Requirements to 
Functions Traceability Matrix 

Shows the mapping between functions 
and functional requirements. 


1. Operational Resource Flow Description for Webfires Training (OV-2) 

This section shows the nodes (or organizations) that make up the WFTS and the 
needlines that connect these organizations. The relationship that this architectural view is 
focusing on in relation to the architectural overview in Section A is shown in Figure 47. 
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Adapted from CORE Architecture Definition Guide (DoDAF v2.02). 
Figure 47. OV-2 Relationship to Overall System Architecture 


According to DoDAF Version 2.02: 

The OV-2 can be used to show flows of funding, personnel and materiel in 
addition to information. A specific application of the OV-2 is to describe a 
logical pattern of resource (information, funding, personnel, or materiel) 
flows. The logical pattern need not correspond to specific organizations, 
systems or locations, allowing Resource Flows to be established without 
prescribing the way that the Resource Flows are handled and without 
prescribing solutions. 

The intended usage of the OV-2 includes: 

• Definition of operational concepts. 

• Elaboration of capability requirements. 

• Definition of collaboration needs. 

• Applying a local context to a capability. 

• Problem space definition. 

• Operational planning. 

• Supply chain analysis. 

• Allocation of activities to resources. (DOD Deputy Chief Information 
Officer 2017c) 

Figure 48 shows the organizations that are involved in the WFTS, which 

organizations pass information between each other, and the general information passed 
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Enemy Treat 


between them. Each needline represents information flow and can be either an input, 
output, or both (represented by the directional arrows) from individual organizations. 



Figure 48. WETS OV-2 


2. Operational Items Transfer Matrix 

The Operational Items Transfer Matrix, as shown in Appendix D, Section A, 
describes in more detail what nodes are connecting to each other and exactly what each 
node is exchanging with the other. This matrix, along with the OV-2, can aid the reader 
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in understanding what and how the organizations can communicate in order to meet the 
capability requirements. 

3. State Transition Description (OV-6b) 

According to DoDAF Version 2.02: 

The OV-6b is a graphical method of describing how an operational 

activity responds to various events by changing its state. 

The intended usage of the OV-6b includes: 

• Analysis of business events. 

• Behavioral analysis. 

• Identification of constraints. (DOD Deputy Chief Information Officer 

20I7e) 

Figure 49 shows the three different states or phases (Support Training, Conduct 
Training, and Evaluate Training) that the WFTS operates under in order to provide 
training. Each one of these phases has different operational activities assosciated with it 
and has different organizations that are involved in each. The figure also shows that this 
is an iterative loop that is completed multiple times to support all phases of the OERP. 
This section discusses each one of the phases in more detail. 



Eigure 49. WETS State Diagram (OV6b) 


4. Operational Activity Model (OV-5b) 

Eigure 50 shows the relationship that the OV-5b has to the architectural overview 
in Section A. An OV-5b is shown for each one of the operational activities shown in 
Eigure 49. Each OV-5b shows the nodes (Organizations) that are involved in that phase. 
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what operational activities they perform, and the Operational Items that are shared 
between the operational activities. 


Nodes 


Performs j 


Operational 

Items 


■^Inputs/Outputs/Triggers 


Operational 

Activities 


Adapted from CORE Architecture Definition Guide (DoDAF v2.02) 

Figure 50. OV-5b Relationship to Architectural Overview 


According to DoDAF Version 2.02: 

The OV-5a and the OV-5b describe the operations that are normally 
conducted in the course of achieving a mission or a business goal. It 
describes operational activities (or tasks); Input/ Output flows between 
activities, and to/from activities that are outside the scope of the 
Architectural Description. 

The OV-5a and OV-5b describes the operational activities that are being 
conducted within the mission or scenario. The OV-5a and OV-5b can be 
used to: 

• Clearly delineate lines of responsibility for activities when coupled with 
OV-2. 

• Uncover unnecessary operational activity redundancy. 

• Make decisions about streamlining, combining, or omitting activities. 
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• Define or flag issues, opportunities, or operational activities and their 
interactions (information flows among the activities) that need to be 
scrutinized further. 

The intended usage of the OV-5a and OV-5b includes: 

• Description of activities and workflows. 

• Requirements capture. 

• Definition of roles and responsibilities. 

• Support task analysis to determine training needs. 

• Problem space definition. 

• Operational planning. 

• Logistic support analysis. 

• Information flow analysis. (DOD Deputy Chief Information Officer 
20I7d) 

How to Read Figure 51, Figure 52, and Figure 53: 

Each parallel line represents a node. Along those lines are boxes that represent the 
operational activities that those nodes perform. Passing between those operational 
activities are operational items. The arrows indicate the flow of operational items from 
one operational activity to the next and show the operational activities that must be 
accomplished prior to the next operational activity. 

Figure 51 shows the operational activities that the Intelligence Community, 
Numbered Fleet, TACTRAGRU, TYCOM, NWDC, and CSG/ESG CMDR perform 
during the Support Training phase of the WFTS. During this phase, NWDC develops 
TTPs that are then passed to the numbered fleet and TYCOM. Additionally, the 
intelligence community will pass intelligence to the other organizations. TACTRAGRU, 
TYCOM, Numbered Fleet, and the CSG/ESG CMDR can then create different training 
scenarios (simulations) for Units, Simulators, or Strike Groups that fit into the Basic, 
Integrated, and Sustainment Phases of the OFRP. 
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Figure 51. Support Training OV-5b 

After the scenarios have been created, the WFTS transitions to the next phase. 
Figure 52. shows the Conduct Training operational activity. During this phase of the 
WFTS, units and simulators receive scenarios and intelligence that were generated and 
collected in the previous phase. This enables units to conduct a variety of different 
training (in-port, at-sea, unit, multi-unit, or any combination). As units and simulators 
conduct this training they are supported by the Numbered Fleet, TACTRAGRU, 
TYCOM, and the CSG/ESG CMDR, who can provide simulation control in order to help 
units meet certain training objectivesrequired to advance through the Basic, Integrated, 
and Sustainment Phases of the OFRP. After a unit or simulator conducts training it will 
then provide feedback data that is used in the next operational activity. 
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Figure 52. Conduct Training OV-5b 


Figure 53 shows the feedback data supplied to the Numbered Fleet, CSG-4/15, 
TYCOM, or CSG/ESG CMDR for evaluation or certification purposes. Additionally, that 
data is passed to the NWDC so that it can be used to assess the TTPs that the Fleet is 
employing and how effective they are against a near-peer threat. If deemed necessary, the 
NWDC can then update the TTPs to allow the fleet to better react to an enemy threat. 
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Figure 53. Evaluate Training 0V-5b 


5. Capability to Operation Activity Mapping (CV-6) 

Figure 54 shows the relationship that the CV-6 has to the architectural overview 
shown in Section A of this chapter. A CV-6 maps the capability requirements that the 
system must have to the operational activities that are used to support those capability 
requirements. The Webfires training system CV-6 is located in Appendix D, Section B. 


139 







Adapted from CORE Architecture Definition Guide (DoDAF v2.02). 
Figure 54. CV-6 Relationship to Overall Architecture 


According to DoDAF Version 2.02: 

The CV-6 describes the mapping between the capabilities required and the 
activities that enable those capabilities. 

The intended usage of the CV-6 includes: 

• Tracing capability requirements to operational activities. 

• Capability audit. (DOD Deputy Chief Information Officer 2017b) 

6. Operational Activity to System Function Traceability Matrix (SV-5a) 

Figure 55 shows the relationship that the SV-5a has to the architectural overview 
shown in Section A of this chapter. An SV-5a maps the Functions to the operational 
activities that they support. This view can be seen in Appendix D, Section C. 


Operational 

Implemented By 

Activities 




Adapted from CORE Architecture Definition Guide (DoDAE v2.02). 
Figure 55. SV-5a Relationship to Architectural Overview 
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According to DoDAF Version 2.02: 

The SV-5a addresses the linkage between System Functions [...] and operational 
activities specified in OV-5a operational activity Decomposition Tree or OV-5b 
operational activity Model. 

The intended usage of the SV-5a ineludes: 

• Traeing funetional system requirements to user requirements. 

• Tracing solution options to requirements. 

• Identification of overlaps or gaps. (DOD Deputy Chief Information 
Officer 20I7f) 

7. Function to System Traceability Matrix 

Figure 56 shows the relationship that the Functions to Systems Traceability 
Matrix has to the architectural overview found in Section A of this chapter. A functions 
to systems traceability matrix maps functions to components that comprise the overall 
system architecture. This viewpoint is shown in Table 30. 



Adapted from CORE Architecture Definition Guide (DoDAF v2.02). 

Figure 56. Funetions to Systems Traeeability Matrix Relationship to Overall 

Arehitecture 
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Table 30. WFTS Functions to Systems Traceability Matrix 


Component 

Function Performs 

Artificial Intelligence Control of Simulation System 

F. 1 Provide Simulation 

Centralized Data Storage System 

F.5 Store Feedback Data 

Combat Systems 

F.3.1 Stimulate Sensors on Units 

Hardwire Communication System 

F.2 Communicate 

LOS Communication System 

F.2 Communicate 

Manual Control of Simulation System 

F. 1 Provide Simulation 

Mesh Network Topology 

F.4 Interface With Network 

OTH Communications System 

F.2 Communicate 

Sat LOS Communication System 

F.2 Communicate 

Simulated Combat Systems 

F.3.2 Stimulate Simulators 

Unit Control System 

F.3.3 Control Simulations 


8. Capability Requirements to Functional Requirements Traceability 
Matrix 

Figure 57 shows the relationship that the Capability Requirements to Functional 
Requirements Traceability Matrix has to the architectural overview found in Section A of 
this chapter. This figure shows that the functional requirements map back to capability 
requirements. The traceability matrix is shown in Appendix D, Section D. 


Capability 

Implemented By 

Functional 

Reauirements 


Reauirements 


Adapted from CORE Architecture Definition Guide (DoDAF v2.02). 

Figure 57. Capability Requirement to Functional Requirement Traceability 
Matrix Relationship to Overall Architecture 

9. Functional Requirements to Functions Traceability Matrix 

Figure 58 shows the relationship that the functional requirements to functions 
traceability matrix has to the architectural overview found in Section A of this chapter. 
System Functions are needed to meet Functional Requirements. The traceability matrix 
can be found in Appendix D, Section E. 
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Adapted from CORE Architecture Definition Guide (DoDAF v2.02). 

Figure 58. Functional Requirements to Functions Traceability Matrix 
Relationship to Overall Architecture 
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XI. SUMMARY, CONCLUSIONS, AND RECOMMENDATIONS 


A. SUMMARY 

The nature of naval warfare is continuously evolving. The traditional kill chain 
approach is expected to be insufficient to neutralize near-peer threats in the future. To 
increase the combat effectiveness of the U.S. Navy in a future combat environment, the 
Navy is shifting its warfighting approach to a kill web, or webfires, concept of 
operations. In his 2016 interview with the U.S. Naval Institute, Admiral Manazir postures 
that unlike the current kill chain process where units are limited to engagements utilizing 
organic sensor data, future units will instead be able to work together to "create a cross¬ 
domain kill web" able to share combat-relevant data for the purpose of tracking and 
engaging an adversary (Manazir 2016). This shift in the way the Navy fights calls for a 
new approach to training the Navy’s future warfighter. This report details a systems 
engineering approach for developing a webfires training system (WFTS) to prepare the 
future warfighter for an engagement with a near-peer threat. 

Using the systems engineering process, the project team used a methodical 
approach to problem identification to derive a problem from the tasking statement issued 
by the primary stakeholder (OPNAV N9I - Director of Warfare Integration). This 
approach included extensive research, stakeholder identification, and stakeholder 
engagement, which helped refine and scope this capstone. Once the research on the 
current Navy training and OFRP cycle was completed, along with stakeholder research, a 
gap analysis was performed to determine what the current training system lacked in 
providing webfires training. This study identified four key capability gaps: the absence of 
any webfires concept training today, a lack of multi-unit training repetition to support 
high-velocity learning, a lack of compatible networks to support webfires training, and a 
lack a quality feedback to facilitate high-velocity learning. 

The Navy is currently developing the webfires concept. The recent deployment of 
the first capable Naval Integrated Fire Control - Counter Air (NIFC-CA) strike group 
demonstrates that such a concept is being developed and implemented by the fleet. The 
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implementation of NIFC-CA is just one small aspect of the webfires concept. If all 
Carrier Strike Group or Expeditionary Strike Group (CSG/ESG) units are able to share 
fire control data with each other, then the webfires concept can be implemented across 
the air, surface, and undersea warfare domains (Manazir 2016). Eor warfighters to 
implement this advanced weapons system effectively, they require doctrine. This report 
recommends that the Naval Warfare Development Center (NWDC) coordinate with the 
other warfare development centers to document a unified set of tactics, techniques, and 
procedures (TTPs) that can be used by all warfighters to implement and train for 
webfires. 

Additionally, the network capability of today’s training system is not robust 
enough to support the repetition necessary to facilitate high-velocity learning and in turn 
results in less efficient multi-unit training. Currently, the only complete CSG/ESG multi¬ 
unit training is performed during Composite Training Unit Exercises (COMPTUEX) 
within the integrated phase of the Optimized Elect Response Plan (OERP) to certify a 
CSG or ESG for deployment and entry into the sustainment phase of the OERP. 
Currently, the Tactical Training Groups (TTG) have the ability to facilitate fleet synthetic 
training (EST) events prior to COMPTUEX. However, due to the nature of the training 
network and the reliance on large numbers of people to conduct these EST events, the 
TTGs can only perform one simulation at a time. A more robust, decentralized training 
network along with a database of preprogrammed training simulations would greatly 
enhance the potential for more frequent integrated training. 

Easily, repetition is only one aspect of high-velocity learning. Eor high-velocity 
learning to be successful, training must be current, accurate, and relevant. This report 
recommends that the future WETS collect and produce data that can be used by the 
NWDC to assess the current doctrine used to engage a near-peer threat. By incorporating 
a feedback loop into the training system, the doctrine can be updated to reflect better 
approaches to attacking an enemy during the training process, and correct deficiencies 
discovered in the doctrine. Additionally, the collected data could be used by the 
appropriate teams in certifying and evaluating units for deployment. This could 
potentially reduce training and certification requirements. However, for this feedback 
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loop to work, the NWDC, along with the certification and evaluation teams, must 
establish well-defined data collection and data processing requirements. 

B. CONCLUSIONS AND RECOMMENDATIONS 

The following conclusions and recommendations will support the U.S. Navy in 
implementing the WFTS: 

I. Training System Architecture for Webfires Concept 

The stakeholders, capability requirements, system requirements, functions, and 
operational activities for the WFTS were identified. Most importantly, the organizations 
and stakeholders determined to be a part of this WFTS were identified along with the 
operational activities they are assigned. These organizations and operational activities 
allow for the support, conduct, and evaluation of webfires training during the basic, 
integrated, and sustainment phases of the OFRP and support high-velocity learning. 

a. Recommendations 

OPNAV N9I: Provide funding and acquisition resources to support the United 
States Fleet Forces (USFF) Command, numbered fleets, TTGs, TYCOMs and NWDC in 
the following tasks. 

USFF: Direct and supervise the implementation of a WFTS and direct the 
Number Fleets, TTGs, TYCOMS, and Warfare Development Centers with the following 
tasks. 

Numbered Fleets: Begin to develop and implement a training strategy that 
includes goals and objectives to train CSG/ESGs using the Webfires Concepts for 
specific mission sets for their areas of responsibility. Additionally, this should be a 
collaborative effort along with the respective TYCOMs, TTGs, and NWDC. 

TTGs: Collaborate with numbered fleets and the TYCOMs in order to help 
develop training goals and objectives to train CSGs and ESGs to implement a webfires 
concept. Additionally, work with units, numbered fleets, and TYCOMs to help create a 
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training scenario database that will allow units to conduct simulated training without 
having to coordinate with a TTG facility. 

TYCOMs: Work with NWDC, TTGs, and numbered fleets to develop training 
goals and objectives to train CSGs and ESGs to implement webfires concepts. 

NWDC: Work with all warfare development centers and the intelligence 
community to fully develop training, tactics, and procedures to implement webfires 
concepts. 

2. Support Training of CSG/ESG Units during the Basic, Integrated, 
and Sustainment Phases of the OFRP 

The envisioned training system is only a relatively small part of the total training 
requirements set to be accomplished during the OFRP. To be effective this system, must 
seamlessly integrate into future concept of operations and future training technologies 
should support this integration through a variety of methods. 

Throughout the different phases of the OFRP we envision the need for integrated 
training to occur at various times of unit readiness, up to and including deployment. In 
order to increase the number of quality repetitions, identified as a current limitation, the 
need to link shore based units with deployed units must increase. The WFTS has 
identified technologies and organizations that support this possibility 

The increase of integrated training within the future envisioned OFRP training 
cycle will improve training quality, retention of training and readiness. The ability to 
work with actual CSG/ESG units and physical contact with unit hardware will produce 
positive measurable results creating stronger team practices. 

Along with increasing quality, the system should provide a greater in-depth 
feedback system. The lessons learned data from each event can be fed back to units in a 
shorter period of time to improve learning. The aviation training model has capitalized on 
an effective feedback system, giving clear results and reinforcing training principles 
immediately after a training event, which from research is the greatest opportunity for 
learning. It is envisioned that a system capitalizing on these principles could be expanded 
to encompass the entire CSG/ESG. 
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a. Recommendation 

USFF, with funding provided by OPNAV N9I, should take the lead on 
implementing integration by directing each involved TYCOM and introducing the 
training system. Their efforts should focus on integrating compatible components along 
with standardized procedures that encourage TYCOM involvement with WFTS. 

3. Leverage High-Velocity Learning through Current and Future 
Technology 

Adversary warfighting capabilities are continuing to grow as future technology 
advancements come to fruition at an exponentially faster rate. To meet these continued 
threats, it is imperative that U.S. service men and women adapt to a new style of learning. 
This style is high-velocity learning, which challenges warfighters to increase the speed of 
the current learning cycle. In a culture of assessments and deep-rooted traditions, it is 
ever more important for warfighters to take charge and execute centered on the 
commander’s intent. As technology continues to advance, the rate of data collection has 
increased as well. By leveraging high-velocity learning, the warfighter is better able to 
process and react to the new and challenging information provided. 

The key to providing high-velocity learning is increasing repetition, providing 
effective feedback, and provide quality training. The future WFTS will provide high- 
velocity learning by incorporating feedback data collection, simulations, and increased 
connectivity. 

• Clear data collection, processing, and distribution requirements must be 
established 

• Investment into being able to provide simulations using real warfighting 
equipment must be made to increase the quality of training 

• lA requirements, network topology, and communications bandwidth 
limitations must be addressed to allow more repetition and repeatability 

a. Recommendation 

N9I should recommend to OPNAV N2/6 they work with warfare development 
centers, TYCOMs and the intelligence community to develop a link that supports the 
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repetitive ideals of high-velocity learning. This link should reinforce learning by 
providing feedback at a sufficient rate, such that lessons learned can be reemployed in 
near real-time. 

4. System Will Be Cost-Effective 

Looking into the future, a quantitative cost effectiveness assessment is difficult to 
assemble at this time. After the 2025-2030 technology has matured, the proposed WFTS 
solution could be better estimated. The cost for the risk/reward and the associated 
technology development and implementation should change the way learning and 
readiness is accomplished in the fleet of tomorrow. 

a. Recommendation 

OPNAV-N9I engage the civilian technology sector to aid in the development of 
simulators and networking infrastructure capable of replacing underway combat training 
exercises with in-port simulations of equal or greater fidelity. It is not recommended to 
replace all underway combat training exercises, but replacing even a small amount of the 
underway training time is expected to have considerable cost savings due to the high 
costs associated with fuel consumption and logistics to get a unit underway. The same 
recommendation holds for reduced flight operations and increased high fidelity flight 
simulations. 

It is understood that there is no substitute for training through actual system 
operation, but when actual system operation is so costly or logistically complex that it 
limits training exercises, there is some benefit to supplementing a portion of the training 
through actual system operations with the more cost-effective and repetitive training that 
simulation can bring. 

C. FURTHER RESEARCH 

The following item are recommended research topics that will complement the 
recommendations contained herein, but were judged to be outside the scope of this report 
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1. Cyber Domain 

During the capstone project, the team focused on developing a training 
architecture for the webfires system. The cyber domain was considered outside the scope 
of the research. The successful employment of WFTS will reply on further research in the 
cyber domain. The team recommends two specific areas of cyber domain for further 
research: cyber security and information assurance. Since the WFTS is network centric, 
it relies heavily on external communication links to share targeting data. Future research 
should focus on how to defend the WFTS and its associated networks from cyber-attacks. 
In addition, most of the current Navy and Marine Corps training systems are stovepipe 
systems. These training systems are built by various contractors and have different 
system classifications. They do not integrate and communicate with one another. Future 
research should focus on information assurance to support systems integration and data 
protection. 

2. Communication Networks 

The WFTS will rely on an exceptionally high level of communications. Further 
research should focus on the entire electromagnetic spectrum to support communications. 
Having a good understanding of all the frequencies will provide a greater insight into all 
the available means of communication for the WFTS and identify the communication 
links that would optimally support WFTS. These communication links could potentially 
increase overall network readiness and training effectiveness. 

One concept for communication speculated during the research was the concept 
of a Link-T. Similar to the concept of Link-16 and CEC, Link-T would be a dedicated 
communication network to execute the WFTS. This Link-T network would be used to 
transmit data for the use of simulation, simulation control data, feedback data, and other 
forms of data or information used to conduct training through the various phases of 
training. 
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3. Artificial Intelligence and Artificial Reality 

In the realm of AI and AR, this project was required to assume optimal and 
streamlined engagement of computer systems to contribute to robust training 
environments. When it comes to computing the decisions and displaying the reactions of 
near-peer threats based on an independent variable of blue force actions and reactions, 
extensive research will be required into topics such as the conceptual and computer 
architecture, software programming requirements, hardware capabilities, and proprietary 
algorithm classification. 

Additionally, the extensive infrastructure requirements that are needed to augment 
reality on actual shipboard equipment or in a shore-based simulator facility pose a 
significant design problem. Further studies on the locations, costs, impacts to the OFRP 
for vessels that are being retrofitted/upgraded to support artificial reality, timeline for 
implementation, and similar information would be needed. 

4. Continue Architecture/Design Including Development of an NTSP 

Based on the tasking statement, the team’s interpretation of that statement, and the 
generation of the unique problem statement, the team delivered a conceptual architecture 
for development of a WFTS. The process essentially paralleled a Material Solutions 
Analysis phase of the DOD Acquisition process and would provide a blueprint for a DOD 
Program Manager to enter Milestone A as seen in Figure 59. 
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The team recommends the Navy assign further research to continue through the 
DOD Acquisition process, beginning with production of a Naval Training Systems Plan 
(NTSP). This would be in accordance with OPNAV 1500.76C, which states: “Programs 
designated with a training KPP [key performance parameter] are required to produce a 
preliminary NTSP at [Milestone-A]” (Chief of Naval Operations 2013). 

Finally, as technologies advance and the webfires concept comes to fruition, the 
team recommends further research on major parts of the Technology Maturation & Risk 
Reduction phase seen in Figure 59. to advance toward requirements needed for a 
Milestone B decision. Such topics include establishment of a Test and Evaluation Master 
Plan, Risk Assessment program, and technology readiness assessment (AcqNotes 2017b). 

5. Acquisitions Stovepiping 

To increase the cross-domain and cross-platform capabilities and trainings, further 
research should focus on system integration during the acquisition process. By 
emphasizing system integration early in the acquisition process, the SME can identify 
essential system integration requirements for the developing systems. Understanding 
these system integration requirements would significantly increase interoperability 
between the developing systems and the established systems. This will result in increased 
integration and readiness of the webfires system and the training system. 

6. Face-to-Face Briefing/Debriefing 

To help increase webfires training effectiveness, further research needs to focus 
on face-to-face briefing and other means of briefing. The face-to-face debriefing process 
involves all the training participants meeting together immediately after the training event 
for a final debrief. Being able to meet face to face to review the previous training event 
can potentially increase teamwork, quality of feedback, and training fidelity. While face- 
to-face debriefing is valuable, it is not always practical out at sea. Further research should 
focus on other means of briefing, such as video teleconference and virtual 
communications. 
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7. Helping of Certification and Evaluation 

The team developed a WFTS that provides training data for evaluation and 
certification. Further research needs to focus on determining what data is required by 
various stakeholders and how to utilize these training data. Being able to utilize these 
training data effectively can potentially increase training effectiveness, reduce evaluation 
and certification time, and update a unit’s readiness. 

8. Warfare Subject Matter Experts 

Based on stakeholder feedback, the team found implementing SMEs has long 
been recognized in the aviation community as a best practice. The aviation community 
retained superior tactical talent for considerable time within an operational environment, 
allowing for quality training that was better retained by the warfighters. The surface 
warfare community has begun to implement procedures that have been modeled after 
these best practices with positive results. As the Navy’s mission begins implementing 
more cross-domain operations, further research will be needed to understand how all 
communities and platforms can produce a cadre of SMEs, and how to best employ their 
time and talent into maximizing benefits from their tactical efficiencies. 
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APPENDIX A. OFFICIAL TASKING STATEMENT 



NAVAL 


f»OS 

SCHOOL 


2 Aui 16 


Memixandum fui SyMems Eii^incettng Analysis Cohon 25 (SEA251 
Suhj: KY20I7 SE.A25 Capsti»ic Ptoyects Taskiitc and Timelines 
(viicloisun*!. 

Tab A: Devetofiing vkvrighidng Iraininit (o leverage the web fires concept and technology 
Tab B NPS Warfare Innovsnion Conrinuum “Strengthen naval power at and from the sea” 

Tab C IRB Student Checklist 

1 This menvurandum peuv ides the FY2017 guidaixe foe the conduct of the Systems 
Hry^inecring Analysis (SFA) integrated project, which is required as partial fulfillment lor the 
SfA degree. ShA students will deliv>er completed project icports and final briefing materials 
to faculty advisors in accordance with the following plan and milestones Each group will: 

a. Develop project pioposals and managcmetit plans during the Fall Quaner AY2017 
These proponis and plans will serve la focus initial research and analysts. Ihea: 
plans will be reviewed and updated ftcqucnily as ttsearch progresses 
b Conduct project reviews appirosimately every six vveeks, fintslung with a final brief to 
interested stakeholders on and off campus. 

C. Assign a report lead from each team. Work ckittely with faculty advisors to prepare 
the final reports for faculty advisor signature by four work-weeks before graduation 
The final reports are then due to the SF.A chairman one week later, and to the 
Operations Research and Systems Engineering depanment chairmen one week before 
graduation 

2 SEA students are expected to identity and integrate students and faculty from across the 
campus - and also from outside NI*S - to paftici|»ie dirtxtiy m the proycct or to provide 
source documents, technical knowledge and iraights, and knowledge of evolving 
requirements, capabilities, and systems. Tlus participation could include students who would 
join project groups, students doing related iiviividual thesis topics from TSSE. TDSI. OR, IS 
or Sf!: faculty inside or outside NPS wliu have e.xpertitc related to the pipjccti and 
appropriately engaged government agencies and industry developers It is the students' 
responsibility to integrate the elTorts of outside porticipiants in the piojccts Faculty advisors 
and the SEA Chair will, of course, significantly assist in these cHorts. 

3. Prior to commerxing the formalized systems engineenng and analysis process including 
stakeholder analysis, tfie SEA team w ill consult with Dr Larry Shatiiick, Chairman of the 
NPS Institutional Review Board and submit to him TAB A, a general desenption of the 
team's systems and analylical appioach H> address the tasking, a completed IRB student 
research form (Tab C) and a Mst of candidate questions for stakeholders to review. Ihc 
intent is to ensure questiorj are oriented about the •what'' of the systems and not about the 
“who- of the stakeholder 
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4 The uMlynii will employ ihe systems engineering and operations research) incihodologies 
presented in class vsork and the project advisors The role of the SEA students b that of 
the lead project systems engineering team, working closely with other members of the project 
engineenng teams from TDSI and other campus curricula SEA students will be expected to 
define the functions and performanoe of systems, develop allemative architectures to meet 
those fyiocuons. and evaluate the alternative architectures for perfomunce and cost In 
executing these tasks, students will be defuiing and understanding the overall prr^l 
requirements, cecogmzing that the definition procc» is iterative and will evolve as the project 
. progresses. 

5. Grades are assigned to the participants in these projects. Although work is perfaraied as putt 
of a team, individual performance will be the basis for this evaluation. Successful completion 
and documentation of the project is a degree requirement 

6. The SEA25 project will build on. possibly challenge, but not replicate, other DOD and SEA 
projects. S^25 will examine virtual environment technologies for potential contributions to 
atablish effective training in web fires tactics and emptoyment SEA25 will coordinate 
their study efforts, participate and occupy leadership roles in other FYI6/I7 efforts at NPS 
aimed at strengthening naval power at and from the sea. Tbeae activities, coordinated by the 
Chair of Systems Engineering Analysis are described in Tab B. 



letYrcy E. Kline 

Chairman, Systems Engineering Analysis Curriculum 
Professor of Practice, Operations Research 
Naval Postgraduate School 
Monterey, CA 93908 


Distribution: SEA2S students; Profs. Hughes, Jacobs, Giachetti. Hatch, Whitcomb, Stevens, 
Solitario. Kline. Hainey, Papoulias, Potter, Boger, BrutTman, Buettner, McDowell, President 
Route; Provost I lensler. Deans Wirtz, Scandrett. McCotmick, Paduan, and Moses. CAPT Dinid 
Verheul. Dr. Shattuck. LCOR Naccarato, RDML Williams, RADM Ellis, Mr. Paul Lhiv 
tOPNAV N9BI. RADM Fanu (OPNAV N9I). Mr. Steve Dreiss (OPNAV N91B). Mr. Mike 
Novak (OPNAV N99B), Mr. Chuck Werchado (N8IB>. and Ms. Kaihie Cain 
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TAB A 


SEA 25 latklMg 

Dfvriopiiii; wnrflKhtinc traininK la levenife neb fires coacepU aad lecbnolofich. 

Design a fleel system of systems and concepc of operations for employment of a coat effective 
tnimng system capable of preparing naval warfighters to employ and leverage the web fires 
concepts and technologies in the 2025-2030 timeframe. Consider training across warfare 
«pM-i«lrie< taui miMlnm rrtndiirs rrsenrrh In provide n itniid fnimdalion of knowtedae 
requirements for a web fires fleet concept. Then complete a gap analysis by comparing current 
(Vert training with the required training to leverage csoss domain and cross-plrtfotm capobilities 
in a warfighning environment Scan for current examples of cross-domain training and current 
training simulation from DoD and industry. Develop a system architecture addressing 
responsible command, training requirements, training and exercise venues, and training 
participants to fill discovered gaps in meeting the knowledge requirements. Assess the proposed 
system againsi the principles of high velocity learning found in the CNO's “A Design lor 
Maintaining Maritime Superiority” 


Advisors; 

Senior Lecturer Bill Hatch. Graduate School of Business atxl Public Policy 

TBD. Systems Engineering Department 

Dr. Michael Atkinson, Operations Research DeparimciM 
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APPENDIX B. OFRP OPERATIONAL ACTIVITY SUMMARY 

TABLE 


OA# 

Operational 

Activity 

Performer 

Input 

Output 

OA.1.1 

Manage 

Sustainment 

Training 

# Fleet 

Commander 

Sustainment 

Training Eeedback 

Unit Sustainment 
Training Status 

Sustainment 

Training 

Requirements 

OA.2.1 

Manage 

Integrated 

Training 

# Fleet 

Commander 

Unit Integrated 
Training Status 

Integrated Training/ 

Certification 

Requirements 

OA.1.2 

Monitor Unit 
Status 

(Sustainment) 

CSG/ESG 

Commander 

Sustainment 

Training Eeedback 

Sustainment 

Training 

Requirements 

Unit Sustainment 
Training Status 


OA.1.3 

Direct Units 
(Sustainment) 

CSG/ESG 

Commander 


Unit Direction 
(Sustainment) 

OA.1.4 

Receive Training 

Requirements 

(Sustainment) 

CSG/ESG Unit 

Sustainment 

Training 

Requirements 


OA.1.5 

Conduct 

Sustainment 

Training 

CSG/ESG Unit 

Unit Direction 
(Sustainment) 


OA.1.6 

Document 

Sustainment 

Training 

CSG/ESG Unit 


Unit Sustainment 
Training Status 

OA.1.7 

Provide 

Sustainment 

Training 

Feedback 

CSG/ESG Unit 


Sustainment 

Training Eeedback 

OA.2.2 

Facilitate 

Integrated 

Training 

TACTRAGROUP 

Integrated Training/ 

Certification 

Requirements 

Integrated Training 

OA.3.1 

Manage Unit 
Level Training 

TYCOM 

Unit Eevel Training 
Eeedback 

Unit Eevel Training 
Status 

Unit Eevel Training/ 

Certification 

Requirements 
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OA# 

Operational 

Activity 

Performer 

Input 

Output 

OA.3.2 

Manage WDCs 

TYCOM 

Unit Eevel Training 
Eeedback 

Doctrine Guidance 

Procedure Guidance 

OA.2.8 

Receive 

Evaluation 

Requirements 

(Integrated) 

Certification 

Programs 

Integrated Training/ 

Certification 

Requirements 


OA.2.9 

Evaluate Units 
(Integrated) 

Certification 

Programs 

Integrated Unit 
Performance 

Unit Integrated 
Training Status 

OA.3.3 

Receive Unit 
Eevel Evaluation 
Requirements 

Certification 

Programs 

Unit Eevel 

Training/ 

Certification 

Requirements 


OA.3.4 

Evaluate Unit 
Eevel 

Performance 

Certification 

Programs 

Unit Eevel 
Performance 

Unit Eevel Training 
Status 

OA.2.3 

Monitor Unit 

Status 

(Integrated) 

CSG/ESG 

Commander 

Integrated Training 
Eeedback 

Integrated Training/ 

Certification 

Requirements 

Integrated Unit 
Performance 

Unit Integrated 
Training Status 


OA.2.4 

Direct Units 
(Integrated) 

CSG/ESG 

Commander 


Unit Direction 
(Integrated) 

OA.2.10 

Receive Training 

Requirements 

(Integrated) 

CSG/ESG Unit 

Integrated Training/ 

Certification 

Requirements 


OA.2.11 

Conduct 

Integrated 

Training 

CSG/ESG Unit 

Integrated Training 
Unit Direction 
(Integrated) 


OA.2.12 

Document 

Training 

(Integrated) 

CSG/ESG Unit 


Integrated Unit 
Performance 

OA.2.13 

Provide 

Integrated 

Training 

Eeedback 

CSG/ESG Unit 


Integrated Training 
Eeedback 
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OA# 

Operational 

Activity 

Performer 

Input 

Output 

OA.3.8 

Receive Training 
Requirements 
(Unit Level) 

CSG/ESG Unit 

Doctrine Guidance 

Procedure Guidance 

Unit Eevel Training/ 

Certification 

Requirements 


OA.3.9 

Conduct Unit 
Training 

CSG/ESG Unit 

Unit Eevel Training 
(Through Eacilities) 


OA.3.10 

Document Unit 
Level Training 

CSG/ESG Unit 


Unit Eevel 
Performance 

OA.3.11 

Provide Unit 

Level Training 
Feedback 

CSG/ESG Unit 


Unit Eevel Training 
Eeedback 

OA.2.5 

Receive 

Integrated 

Training 

Requirements 

Elect Eevel 
Training Eacility 

Integrated Training/ 

Certification 

Requirements 


OA.2.6 

Provide 

Interactive 

Training 

(Integrated) 

Elect Eevel 
Training Eacility 


Integrated Training 

OA.2.7 

Evaluate 

Interactive 

Training 

(Integrated) 

Elect Eevel 
Training Eacility 

Integrated Unit 
Performance 

Integrated Training 
Eeedback 

Unit Integrated 
Training Status 

OA.3.5 

Receive Unit 
Level Training 
Requirements 

Elect Eevel 
Training Eacility 

Unit Eevel Training/ 

Certification 

Requirements 


OA.3.6 

Provide 

Interactive Unit 
Level Training 

Elect Eevel 
Training Eacility 


Unit Eevel Training 
(Through Eacilities) 

OA.3.7 

Evaluate Unit 
Eevel Interactive 
Training 

Elect Eevel 
Training Eacility 

Unit Eevel 
Performance 

Unit Eevel Training 
Status 
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APPENDIX C. COMPONENT TRADE-OEE ANALYSIS SUMMARY 



Category 

Advantages 

Disadvantages 

Provide Simulations 

Artificial 

Intelligence 

- Potential to Mimic Tactical 
Fidelity of Manual Control 

- Not Relying on SME to Run 
Scenarios 

- Expensive to Program and 
Develop 

- Time Intensive to Develop 

Manual 

- Realistic Tactics 

- Highest Fidelity Tactics (Real 
Time Responses and Delays) 

- High SME Demand 

- Eabor Intensive 

- Time Consuming 

Preprogrammed 

- Low Cost 

- High Repetition 

- Range Greatly in Complexity 

- Easily Tailored to Meet 

Training Objectives 

- Eowest Fidelity 

- Potentially “Game” the 
Scenario after a Few 
Repetitions 

Communicate 

Hard Wire (LAN 
Line) 

- High Data Rate 

- Cheap and Simple over Short 
Distances 

- Does Not Have At-Sea 
Capability 

- Expensive over Fong 
Distances 

Over The 

Horizon (OTH) 

- Greater Ranges than EOS 
Communications 

- Eowest Data Rate 
-HE possible RADHAZ 

Line Of Sight 
(LOS) 

- Eow cost 

- Not Relying on SATCOMS 
-Moderate to high data rates 

- No Over the Horizon 
Capability 

- Point to Point EOS between 
Ships in Port Might be A 
RADHAZ 

Satellite Corns 

-Cover Great Ranges 
-Moderate Data Rates 

-High Cost 

Stimulate Units 

Non-Console 

- Eow Cost 

- Great for Individual Training 

- Eowest Fidelity 

Simulated 

Console 

- Great for Unit Training 

- Available to Multiple Units 

- Medium to Eow Fidelity 

- Does Not Train to 

Equipment Operation 

Actual Console 

- Highest Fidelity 

- Expensive Simulators/ 
Facilities 

Simulati 

Central Control 

- Unity of Command 

- SME Only Needed at Central 
Eocation 

- Single Point of Failure 

- Potentially Eimited 

Repetition 
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Local Control 

- Not Required Central Control 

- Unity of Command 

- Potentially Increased Repetition 

- Single Point of Eailure 

Unit Control 

- All Webfires Capable Units 

Can Control Simulation 

- Increases Repetition 

- Not Relying on Central or 

Local node 

- Difficult to Manage Earge 
Training Events 

Interface with Network 

Star Network 
(Shore-Side) 

- Central Hub Controls and 
Monitors All Units 

- Easy to Connect and 

Disconnect from Central Hub 

- Single Point of Eailure 

- All Non-Central Units Must 
Connect to a Central Hub 

Multiple-Stars 
(Shore and Sea) 

- Enable More Units to Joint 
Training 

- Easy to Connect and 

Disconnect from Central Hub 

- Single Point of Eailure 

- All Non-Central Units Must 
Connect to a Central Hub 

Mesh Network 

- Very Reliable 

- Expensive 

- Very Complicated 

Store Data 

Centralized 

- Whole Picture Data 

- Highly Accessible 

- Single Point of Eailure 

Local 

- Units Can Recall Own Data 
Independent of Networks 

- Must Have Storage 

Capability at Each Unit 

- Partial Picture Data 

Portable Media 

- Eow Cost 

- Convenient 

- Must Have Storage 

Capability at Each Unit 

- Time Delay to Transfer 

Media from Portable Storage 
to Destination 

- Partial Picture Data 
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APPENDIX D. WEBFIRES TRAINING SYSTEM ARCHITECTURE 


A. OPERATIONAL ITEMS TRANSFER MATRIX 


Nodes 

Connected To 

Operational Items 
Transferred 

Description 

#Fleet 

Unit/Simulator 

Control & Data & Scenario 

Data (Feedback Data) will be 
passed from Units and 

Simulators for the purpose of 
evaluation or certifications. 

Scenarios and control of those 
scenarios will be passed to Units 
and Simulators from the #Fleet, 
TYCOM, TACTRAGRU, or 
CSG/ESG CMDR. 

TYCOM 

Unit/Simulator 

Control & Data & Scenario 

TACTRAGRU 

Unit/Simulator 

Control & Data & Scenario 

CSG/ESG CMDR 
Unit/Simulator 

Control & Data & Scenario 

Intel Community 
TACTRAGRU 

Enemy Capabilities/Tactics 

The Intelligence Community 
will update and pass the enemies 
capabilities and tactics to the 
organizations that are involved 
in running the Units/Simulators 
as well as the Units/Simulators 
themselves. 

#Fleet 

Intel Community 

Enemy Capabilities/Tactics 

Intel Community 
Unit/Simulator 

Enemy Capabilities/Tactics 

Intel Community 
TYCOM 

Enemy Capabilities/Tactics 

CSG/ESG CMDR 
Intel Community 

Enemy Capabilities/Tactics 

CSG-4/15 

Unit/Simulator 

Data 

Data (Feedback Data) will be 
passed to NWDC for use to 
update TTPs. Additionally, data 
will be used for evaluation or 
certification by the CSG-4/15 
responsible for certifying a 

Strike Group for deployment. 

NWDC 

Unit/Simulator 

Data 

#Eleet 

TYCOM 

Training Objectives 

The #Fleets and the TYCOMs 
will pass training objectives to 
the organizations that are 
responsible for establishing 
training scenarios and training 
Units and Strike Groups. 

#Fleet 

CSG/ESG CMDR 

Training Objectives 

TACTRAGRU 

TYCOM 

Training Objectives 

CSG/ESG CMDR 
TYCOM 

Training Objectives 

#Fleet 

Training Objectives 
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Nodes 

Connected To 

Operational Items 
Transferred 

Description 

TACTRAGRU 



#Fleet 

TTP 

NWDC will provide Webfires 

NWDC 

TTPs that can be used to 

NWDC 

TTP 

establish Training Objectives for 

TYCOM 

Units and Strike Groups. 
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B. 


WEBFIRES TRAINING SYSTEM CV-6 TABLE 


Cap Req# 

Capability 

Requirements 

Operational Activities 

CapReq.l 

Repetition 

CapReq.1.1 

Provide Training 
Scenarios 

OA.1.1 Collect Intel on Enemy 

OA.1.4 Provide Multi-Unit (Cross Domain) Scenarios 
OA.1.6 Establish Multi-Unit Scenarios 

OA.1.7 Establish Unit Scenarios 

CapReq.l. 2 

Run simulations 
independently 
between units and 
simulators 

OA.2.1 Eacilitate Elect Scenarios 

OA.2.2 Eacilitate (Cross Domain) Scenarios 

OA.2.3 Eacilitate Scenarios 

OA.2.4 Eacilitate CSG/ESG Scenarios 

OA.2.5 Create/Modify/Receive Scenarios 

OA.2.6 Conduct In-port Unit Training 

OA.2.7 Conduct At-Sea Unit Training 

OA.2.8 Conduct At-Sea Multi-Unit Training 

OA.2.9 Conduct In-Port Multi-Unit Training 

OA.2.10 Conduct Hybrid Training 

CapReq.l.3 

Train with limited 
communications 

OA.2.1 Eacilitate Elect Scenarios 

OA.2.2 Eacilitate (Cross Domain) Scenarios 

OA.2.3 Eacilitate Scenarios 

OA.2.4 Eacilitate CSG/ESG Scenarios 

OA.2.5 Create/Modify/Receive Scenarios 

OA.2.6 Conduct In-port Unit Training 

OA.2.7 Conduct At-Sea Unit Training 

OA.2.8 Conduct At-Sea Multi-Unit Training 

OA.2.9 Conduct In-Port Multi-Unit Training 

OA.2.10 Conduct Hybrid Training 

CapReq.2 

Feedback 

CapReq.2.1 

Provide Data for 
certification and 
evaluation 

OA.2.11 Produce Eeedback 

OA.3.1 Evaluate Elect 

OA.3.2 Certify ESG/CSG for Deployment 

OA.3.3 Certify Eor Entry into Advanced Phase 

OA.3.4 Evaluate Type Training 

OA.3.6 Evaluate CSG/ESG 

CapReq.2.2 

Provide Data to 
update TTP 

OA.2.11 Produce Eeedback 

OA.3.5 Evaluate Doctrine/Tactics/Procedures 

CapReq.3 

Integration 

OA.2.6 Conduct In-port Unit Training 

OA.2.7 Conduct At-Sea Unit Training 

OA.2.8 Conduct At-Sea Multi-Unit Training 

OA.2.9 Conduct In-Port Multi-Unit Training 

OA.2.10 Conduct Hybrid Training 

CapReq.4 

Webfires Concept Training 
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Cap Req# 

Capability 

Requirements 

Operational Activities 

CapReq.4.1 

In-port and At-sea 

OA.1.8 Create Doctrine/Tactics/Procedures 

OA.2.6 Conduct In-port Unit Training 

OA.2.7 Conduct At-Sea Unit Training 

OA.2.8 Conduct At-Sea Multi-Unit Training 

OA.2.9 Conduct In-Port Multi-Unit Training 

OA.2.10 Conduct Hybrid Training 

CapReq.4.2 

Multi-Unit and 

Unit Training 

OA.1.8 Create Doctrine/Tactics/Procedures 

OA.2.8 Conduct At-Sea Multi-Unit Training 

OA.2.9 Conduct In-Port Multi-Unit Training 

OA.2.10 Conduct Hybrid Training 

CapReq.4.3 

OFRP 

OA.1.2 Establish Fleet Training Objectives 

OA.1.3 Establish Fleet Scenarios 

OA.1.4 Provide Multi-Unit (Cross Domain) Scenarios 
OA.1.5 Establish Type Training Objectives 

OA.1.6 Establish Multi-Unit Scenarios 

OA.1.7 Establish Unit Scenarios 

OA.1.8 Create Doctrine/Tactics/Procedures 

OA.1.9 Establish CSG/ESG Scenarios 

OA.2.1 Facilitate Fleet Scenarios 

OA.2.2 Facilitate (Cross Domain) Scenarios 

OA.2.3 Facilitate Scenarios 

OA.2.4 Facilitate CSG/ESG Scenarios 

OA.2.5 Create/Modify/Receive Scenarios 
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c. 


WEBFIRES TRAINING SYSTEM SV-5A TABLE 


OA# 

Operational Activity 

Implemented By 

OA.l 

Support Training 

OA.1.1 

Collect Intel on Enemy 

No Eunction to support this 
operational activity 

OA.1.2 

Establish Elect Training 
Objectives 

No Eunction to support this 
operational activity 

OA.1.3 

Establish Elect Scenarios 

E.1.1 Create Simulation 

E.1.2 Store Simulation 

E.1.3 Modify Existing Simulation 
E.1.4 Receive Intel Updates 

OA.1.4 

Provide Multi-Unit (Cross 
Domain) Scenarios 

E.1.1 Create Simulation 

E.1.2 Store Simulation 

E.1.3 Modify Existing Simulation 
E.1.4 Receive Intel Updates 

OA.1.5 

Establish Type Training 
Objectives 

No Eunction to support this 
operational activity 

OA.1.6 

Establish Multi-Unit Scenarios 

E.1.1 Create Simulation 

E.1.2 Store Simulation 

E.1.3 Modify Existing Simulation 
E.1.4 Receive Intel Updates 

OA.1.7 

Establish Unit Scenarios 

E.1.1 Create Simulation 

E.1.2 Store Simulation 

E.1.3 Modify Existing Simulation 
E.1.4 Receive Intel Updates 

OA.l.8 

Create Doctrine/Tactics/ 
Procedures 

No Eunction to support this 
operational activity 

OA.l.9 

Establish CSG/ESG Scenarios 

E.1.1 Create Simulation 

E.1.2 Store Simulation 

E.1.3 Modify Existing Simulation 
E.1.4 Receive Intel Updates 

OA.2 

Conduct Training 

OA.2.1 

Eacilitate Elect Scenarios 

E.1.5 Receive Simulations 

E.3.3 Control Simulations 

E.4.1 Interface with Human 

E.4.2 Interface With System 

OA.2.2 

Eacilitate (Cross Domain) 
Scenarios 

E.1.5 Receive Simulations 

E.3.3 Control Simulations 

E.4.1 Interface with Human 

E.4.2 Interface With System 
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OA# 

Operational Activity 

Implemented By 

OA.2.3 

Facilitate Scenarios 

FT.5 Receive Simulations 

F.3.3 Control Simulations 

F.4.1 Interface with Human 

F.4.2 Interface With System 

OA.2.4 

Facilitate CSG/ESG Scenarios 

F.1.5 Receive Simulations 

F.3.3 Control Simulations 

F.4.1 Interface with Human 

F.4.2 Interface With System 

OA.2.5 

Create/Modify/Receive 

Scenarios 

F.1.1 Create Simulation 

F.1.2 Store Simulation 

F.1.3 Modify Existing Simulation 
E.1.4 Receive Intel Updates 

E.1.5 Receive Simulations 

E.2.3 Transmit Simulations 

OA.2.6 

Conduct In-port Unit Training 

E.2.2 Transmit Voice 

E.3.1 Stimulate Sensors on Units 

E.3.2 Stimulate Simulators 

E.3.3 Control Simulations 

E.4.1 Interface with Human 

E.4.2 Interface With System 

OA.2.7 

Conduct At-Sea Unit Training 

E.2.2 Transmit Voice 

E.3.1 Stimulate Sensors on Units 

E.3.2 Stimulate Simulators 

E.3.3 Control Simulations 

E.4.1 Interface with Human 

E.4.2 Interface With System 

OA.2.8 

Conduct At-Sea Multi-Unit 
Training 

E.2.2 Transmit Voice 

E.3.1 Stimulate Sensors on Units 

E.3.2 Stimulate Simulators 

E.3.3 Control Simulations 

E.4.1 Interface with Human 

E.4.2 Interface With System 

OA.2.9 

Conduct In-Port Multi-Unit 
Training 

E.2.2 Transmit Voice 

E.3.1 Stimulate Sensors on Units 

E.3.2 Stimulate Simulators 

E.3.3 Control Simulations 

E.4.1 Interface with Human 

E.4.2 Interface With System 
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OA# 

Operational Activity 

Implemented By 

OA.2.10 

Conduct Hybrid Training 

E.2.2 Transmit Voice 

E.3.1 Stimulate Sensors on Units 

E.3.2 Stimulate Simulators 

E.3.3 Control Simulations 

E.4.1 Interface with Human 

E.4.2 Interface With System 

OA.2.11 

Produce Feedback 

E.5.1 Store Performance Data 

P.5.2 Store Event Data 

OA.3 

Evaluate Training 

OA.3.1 

Evaluate Eleet 

P.2.1 Transmit Peedback Data 

OA.3.2 

Certify ESG/CSG for 
Deployment 

P.2.1 Transmit Peedback Data 

OA.3.3 

Certify Eor Entry into 

Advanced Phase 

P.2.1 Transmit Peedback Data 

OA.3.4 

Evaluate Type Training 

P.2.1 Transmit Peedback Data 

OA.3.5 

Evaluate Doctrine/Tactics/ 
Procedures 

P.2.1 Transmit Peedback Data 

OA.3.6 

Evaluate CSG/ESG 

P.2.1 Transmit Peedback Data 
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D. CAPABILITY REQUIREMENTS TO FUNCTIONAL REQUIREMENTS 
TRACEABILITY MATRIX 


CapReq# 

Capability Requirements 

Functional Requirement 

CapReq.l 

Repetition 

CapReq. 1.1 

Provide Training Scenarios 

Req 3 Receive Intel Updates 

Req 5 Preprogrammed Simulations 
Req 6 Modify Simulations 

Req 7 Create Simulations 

Req 11 Provide Simulation Storage 

CapReq. 1.2 

Run simulations independently 
between units and simulators 

Req 8 Simultaneous Simulations 

Req 9 Support Multiple Simulations 
Req 10 Simulation Control 

CapReq. 1.3 

Train with limited 
communications 

Req 14 Communication 

CapReq.2 

Feedback 

CapReq.2.1 

Provide Data for certification and 
evaluation 

Req 12 Collect and Provide Data 

Req 13 Aid Cert and Eval 

CapReq.2.2 

Provide Data to update TTP 

Req 12 Collect and Provide Data 

CapReq.3 

Integration 

Req 1 Integrate CSG/ESG Units’ 
Weapon Systems 

Req 2 Interface with Training 

Eacilities and Simulators 

Req 4 Compatibility 

CapReq.4 

Webfires Concept Training 

CapReq.4.1 

In-port and At-sea 

Req 1 Integrate CSG/ESG Units’ 
Weapon Systems 

Req 2 Interface with Training 

Eacilities and Simulators 

Req 4 Compatibility 

CapReq.4.2 

Multi-Unit and Unit Training 

Req 1 Integrate CSG/ESG Units’ 
Weapon Systems 

Req 2 Interface with Training 

Eacilities and Simulators 

Req 4 Compatibility 
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CapReq# 

Capability Requirements 

Functional Requirement 

CapReq.4.3 

OFRP 

Req 1 Integrate CSG/ESG Units’ 
Weapon Systems 

Req 2 Interface with Training 

Facilities and Simulators 

Req 4 Compatibility 

Req 12 Collect and Provide Data 

Req 13 Aid Cert and Eval 
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E. FUNCTIONAL REQUIREMENTS TO FUNCTIONS TRACEABILITY 
MATRIX 


Req # 

Requirement 

Basis Of 



F.3.1 Stimulate Sensors on Units 

F.4.2 Interface With System 

1 

Integrate CSG/ESG Units’ 
Weapon Systems 

F.4.2.1 Provide Multi-Unit Network 

F.4.2.1.1 Connect Units 

F.4.2.1.1.1 Connect Units In-port 

F.4.2.1.1.2 Connect Units At-sea 

F.4.2.2 Provide Standalone Network 



F.4.2 Interface With System 

0 

Interface with Training 

F.4.2.1 Provide Multi-Unit Network 

z 

Facilities and Simulators 

F.4.2.1.2 Connect Simulators 

F.4.2.2 Provide Standalone Network 

3 

Receive Intel Updates 

F.1.4 Receive Intel Updates 

4 

Compatibility 

F.1.4 Receive Intel Updates 



F.1.1 Create Simulation 

5 

Pre-Programmed Simulations 

F.1.2 Store Simulation 

F.1.5 Receive Simulations 

6 

Modify Simulations 

F.1.3 Modify Existing Simulation 

7 

Create Simulations 

F.1.1 Create Simulation 



F.3.1 Stimulate Sensors on Units 

F.3.2 Stimulate Simulators 

8 

Simultaneous Simulations 

F.3.3 Control Simulations 

F.4.1 Interface with Human 

F.4.1.1 Provide Control Display 

F.4.1.2 Provide HMI 



F.3.1 Stimulate Sensors on Units 

F.3.2 Stimulate Simulators 

F.3.3 Control Simulations 

9 

Support Multiple Simulations 

F.4.1 Interface with Human 

F.4.1.1 Provide Control Display 

F.4.1.2 Provide HMI 

F.4.2.1 Provide Multi-Unit Network 

F.4.2.2 Provide Standalone Network 

10 

Simulation Control 

F.3.3 Control Simulations 

F.4.1 Interface with Human 

F.4.1.1 Provide Control Display 

F.4.1.2 Provide HMI 



11 

Provide Simulation Storage 

F.1.2 Store Simulation 

12 

Collect and Provide Data 

F.5.1 Store Performance Data 
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Req# 

Requirement 

Basis Of 



F.5.2 Store Event Data 

13 

Aid Cert and Eval 

E.5.1 Store Performance Data 

E.5.2 Store Event Data 

14 

Communication 

E. 2.1 Transmit Feedback Data 

F. 2.2 Transmit Voice 

F.2.3 Transmit Simulations 
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APPENDIX E. IRB DOCUMENTATION 


A. ORIGINAL SEA-25 CAPSTONE PROJECT QUESTIONS 


Mission (Tasks): 

1. Define the scale of “web-fires” in the realm of Air/Surface/Undersea/Cyber, 

a. What types of training will be required? 

2 . Are there specific Mission Essential Task Lists (METE) items for this 
project for cross-domain training? 

a. What are the prioritization levels of these METLs? 

b. Who are the primary stakeholders that would define the most significant 
METLs? 

c. Are there METLs that we should seek to focus on for creating training 
and developing tactics? 

3. What is the expectation of effective tactical training? 

Cross-Domain Training: 

1. What are the existing technologies used for cross-domain training? 

2 . What are some challenges to incorporate cross-domain communications with 
webfires? 

3. What training systems are currently available for incorporation of webfires? 

4. What current capabilities do systems provide in integrated training? 

How does [insert company/organization name] approach cross-domain 
training? 

a. Addressing the challenges/constraints listed above, how does 
the respective [company/organization name] incorporate and 
adapt to these challenges? 

b. What technology is capable of operating in a webfires environment? 

c. Is this platform specific training or universal? 

5. What challenges have [insert company/organization name] encountered 
in cross-domain training? 

a. Particularly from the perspective of joint interoperability 

b. Particularly from the perspective of operating in an integrated 
communications environment 

6. What requirements would [insert company/organization name] place on a 
system operating in the cross-domain training environment? 

a. Do these requirements align with the requirements that we have been 
given for this project? 

b. Should additional requirements be added to help scope-down our project? 

c. How are these requirements prioritized? 

i. What are the Key Performance Parameter (KPP) requirements 
(aka the “non- negotiables”)? 

7. What current Navy/Joint systems support integrated webfires training? 
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a. Cooperative Engagement Capability (CEC)? 

b. Eink 11/16? 

c. Battleforce Tactical Trainer (BETT) 

Infrastructure Security: 

1. What controls are made to prevent an adversary from gaining access or 
disturbing these training systems? 

a. Compromising training by hacking into / stealing / destroying, etc. 

2 . What are the challenges in communication with a network of webfires 
especially underwater units? How is bandwidth to be controlled if there are 
multiple units or nodes in use at one time in the same network? 

3. How will these training platforms maintain comms with other platforms in 
EMCON status? 

a. What are the challenges? 

b. What is the way-around? 

4. What will webfires be capable of be in 10 years? 
a. All domains (Air/Surface/Sub-surface) 

5. What capabilities will the training system have in terms of 
communicating with other platforms? 

6. What other training systems are currently being fielded? 

a. EM environment (jamming)? 

b. Eong-range communications extension? 

c. Weapons delivery? 

d. Stand-Alone? 

7. What is the envisaged extent of this system for U.S. military training? 
a. Does it replace manned systems or complement them? 

8. What are the challenges experienced by users when dealing with cyber 
training? 

Technology: 

1. What sensors are currently available for incorporation into the training? 

Are these sensors capable of operating in a denied environment? How 
would the information that these sensors obtain be relayed to the training 
system? 

a. Once information is gathered by a sensor, what is the network path for 
delivery? 

2. Are we seeking to strictly use existing capabilities and repurposing 
AND/OR develop an entirely new system? 

a. Is there a system currently being fielded that supports interoperability 
training in a denied environment? Can we use that training system 
as a template/model for our future defined training system? (Eor 
example: Does our prospective training system mimic other systems 
such as NIEC-CA or other Integrated Eire Control (lEC) related 
systems or BETT?) 
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3. Will the U.S. Navy have technology that will be capable of passing 
large amounts of data through the water that will have the speed of 
kbps, or mbps, not the current bps? 

4. What are the considerations to develop the next generation of C4ISR 
network centric architecture to support cross-domain training? 
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B. MODIFIED SEA-25 CAPSTONE PROJECT QUESTIONS 


Training and High-velocity Learning 

1. What technologies are used to train? (VR? Simulators? Classrooms? Online?) 

2. Are the scenarios preset? Is Computer Artificial Learning used at all? Are Human 
(Blue) vs. Human (Red) simulator scenarios used at all? 

3. What is the process for modifying simulator scenarios? 

4. How are the most up-to-date enemy’s tactics and capabilities integrated into current 
training? 

5. How do the instructors interact with the simulators? 

6. How is training performed with the simulators? 

7. How is doctrine and procedure taught? 

Multi-Domain Training Architecture 

1. What documented challenges are experienced regarding cross-domain training? 

2. How are other communities (such as SWOs/IAMD WTI) integrated into the training? 

3. How does _ (Company/Command) integrate with other training facilities and 

other communities across the Navy? 

Feedback and Future Improvements 

1. How is training curriculum feedback reported and implemented? 

2. How is simulator HW/SW feedback reported and implemented? 

3. How is feedback used to update training, doctrine, and procedures? 

4. How is feedback incorporated in updating the warfighting systems and training 
systems? 

5. What improvements are planned for the next generation training facility or 
architecture? 

Current Capabilities 

1. What is the current_(Company/Command) training pipeline/architecture? 

2. What improvements are planned for the next generation_(Company/Command) 

training facility or architecture? 

Requirements 

1. What training requirements are directed to_(Company/Command) from above? 

2. What pre-requisites are required for training at_(Company/Command)? 

3. What pre-requisites or requirements are there to initiate integrated training? 

4. What are documented requirement gaps? 

Evaluation 

1. What are the documented training objectives for units/students? 

2. How is the units’/students’ performance evaluated? 


182 



4^ U> K) 


Training Logistics 

1. How many hours a day do students spend in the current system? 

. What is the current system throughput/capacity? 

. What does the current system cost to build/purchase? To operate? 
. How are simulators integrated with other simulators? 
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